0

I have a VS2015 solution with a webUI project and a class lib project which acts as the domain. The class lib holds nothing more then 20 EF DB First generated classes (edmx model) and also 20 repo's which act on these classes. When I need to change the underlying db I throw away the edmx model and regenerate it. One of these classes is Domain.DbEntities.plc. My webUI references this domain lib.

After some time I added an extra project PlcCommunicator to the solution, which has a reference to the Domain lib and has methods some accepting Domain.DbEntities.plc as parameter and some returning wrapper classes which also use Domain.DbEntities.plc. My webUI project references the "PlcCommunicator" project and everything works fine.

The solution is growing larger and by the time I added more projects to it all refering and using the same Domain lib. But now I have added another project called PlcMonitoringLogger and I decided to create another smaller domain, just a subset of the main domain, which holds 5 classes which are all also just EF DB First generated edmx classes generated on the same db as the Main Domain. One of these classes is PlcMonitoringDomain.DbEntities.plc. (Note the difference with Domain.DbEntities.plc)

Now I need my PlcMonitoringLogger project to use the PLCCommunicator project. But PlcCommunicator works with Domain.DbEntities.plc and PlcMonitoringLogger only knows PlcMonitoringDomain.DbEntities.plc. So there is the problem I face.... I can change the parameters of the PlcCommunicator methods to accept plc id's instead of Domain.DbEntities.plc object's and also just return plc id's instead of Domain.DbEntities.plc objects. However, is this the right approach? Are there any pitfalls? What are the pros and cons? Another solution might be to create a base plc class, but this doesn't seem right. I want to decouple things from each other and creating base classes just doesn't feel right.

I read some stuff about bounded context's. But I can't and don't want to change al my existing projects right away to using this design pattern. Not in the last place because I have no experience in it yet and it's hard for a beginner. I think making "baby steps" to using some aspects off bounded context are the best approach, not doing total rebuilds!

So if anybody has some ideas on this topic or something useful to say please, respond!

Maarten
  • 22,527
  • 3
  • 47
  • 68
Kip ei
  • 479
  • 6
  • 20
  • Decoupling things is not achieved by putting it in different projects. It is best achieved (IMHO) by programming to abstractions, not implementations. – Maarten Dec 14 '16 at 11:10

1 Answers1

0

I'm not sure what you tried to achieve by creating a subdomain, but the consequence is that they are not interchangable. So if you want to combine component which results in a domain mix-up, then you cannot do that.

IMHO, the solution is to get rid of the sub-domain, and integrate it in the current main-domain. Any project/component using the domain can without problem reference other components that use the domain as well. No multiple domains mix-up.

Maarten
  • 22,527
  • 3
  • 47
  • 68
  • The "Main Domain" is getting bigger over time and some small projects(services) only need 2 or 3 entities from the "Main Domain" to do what I design them to do. So it doens't make sence to use this whole "Main Domain" in these projects and yet I do. This is why I decided to change my design habbit with this new small service(project) I need. Maybe I can split my "Main Domain" into let's say 5 subdomains. Where small projects(services) use 1 or 2 subdomain's and the webUI use all 5(or less if it doesn't need 1). Ofcourse communicating with the ID's of objects instead of the objects themselfs. – Kip ei Dec 14 '16 at 12:47
  • Why doesn't it make sense to keep it as a simple domain? You tried to separate it into pieces, but apparently it comes back to bite you when you try to use one component from another. – Maarten Dec 14 '16 at 12:48
  • But this approach is totally new for me, so I am asking for any known pitfalls, pros and cons or other userfull advice. So thnkx for your response at least! More responses (also from other folks) are still very welcome ;) – Kip ei Dec 14 '16 at 12:50
  • Keep using 1 big domain is a very real scenario! I saw this [presentation](https://www.youtube.com/watch?v=CjNBnkMHjh4), see diagram in min 14, and tried to use some aspects of it. – Kip ei Dec 14 '16 at 12:56