7

We are discussing how to implement Domain Driven Design.

Are there any immediate drawbacks to using a separate project for each bounded context?

All thoughts and suggestions on our approach are welcome.

So it would look like:

- ProjectA.dll (User Context Web Service)
    - References 
        - ProjectB.dll

- ProjectB.dll (User Context Domain)

- ProjectC (Web App)
    - References
        - ProjectD.dll
        - REST calls to ProjectA for User stuff

- ProjectD.dll (Product Context Domain)

- ProjectE.dll (Some Other Context)
    - Domain
        - Service
            - IService.cs
        - DTO
            - DTO A.cs
        - Entity
            - Entity A.cs
            - Entity B.cs
    - Repository
        - Repo.edmx

We are considering making some bounded contexts accessible only via web services to allow for scalability of areas that could get heavy traffic.

drizzie
  • 3,351
  • 2
  • 27
  • 32
  • 3
    Looking at your design, I would favour sub-categorising by component and not by type. I.e. instead of having 'Service', 'DTO' and 'Entity' folders, maybe let the naming of these things do the work and instead name the folders after functional areas. I.e. maybe 'Ordering', 'Invoicing', 'Administration', etc. – Adrian Thompson Phillips Feb 06 '16 at 16:10
  • 1
    In the above example, each individual project is representative of a functional area. – drizzie Feb 06 '16 at 21:48
  • I am curious to know how did you manage the context mapping? what was the kind of relationships and technologies used for context mapping? – Mohammed Noureldin Feb 01 '22 at 04:48

2 Answers2

9

The answer to this question is not as straight-forward as it may initially appear. This is because there are different ways to integrate BCs.

This question (and answer) summarize the problem pretty well:

One approach is to consider the whole application a BC, and the other is to only consider the domain logic a BC.

To answer your question, we clearly have to differentiate between the two.

Case 1: BC manifests as whole application

This is the scenario where you typically have one development team per application (and BC by extension). Consequently, a suitable VS solution and project setup is to create one solution per application, and structure the projects according to logical layering.

Case 2: BC manifests as domain logic library

Here, it could make sense to put everything in one solution if the overall application is not too big. Otherwise, extract supporting BCs into their own solution as required. This is often driven by team organization.

To apply this to your case, I think your suggestion is a good starting point. If the solution grows too big, you could later take the user stuff out and move it into a dedicated solution. The important thing here is to have well-defined BC borders and interfaces. With that, it is easier to move stuff later.

Community
  • 1
  • 1
theDmi
  • 17,546
  • 6
  • 71
  • 138
  • Nice answer. Recent trend around microservices will draw people more towards option #1 I think, but #2 is valuable as well. – guillaume31 Feb 08 '16 at 11:58
  • @guillaume31 Thanks for the remark. Case 1 does indeed make more sense in a microservices architecture. – theDmi Feb 08 '16 at 12:07
  • This is a fantastic answer and has exposed me to some things that we need to consider further. Thanks! – drizzie Feb 08 '16 at 14:18
  • 1
    @drizzie You're welcome. An interesting side note on case 2 above: In "Implementing DDD", Vaughn Vernon even suggests that an app service layer that integrates several BCs could be seen as a mini BC that models the combination of the downstream BCs. – theDmi Feb 08 '16 at 15:15
  • Feel free to provide insight on my next question http://stackoverflow.com/q/35283061/1286925 – drizzie Feb 09 '16 at 02:47
1

What you have displayed appears to be more of a layering approach to solution architecture with the presentation, application, domain and infrastructure layers split out. These would be separate projects within the same solution (I'm a C# developer so I think in terms of Visual Studio).

I would think that using separate solutions would be the right course of action to segregate bounded contexts though. That's if you are going down the path of mapping applications and persistence concerns to bounded contexts. If true, different teams can work on each application without needing to operate within the same solution space.

Hope that helps...

Venture
  • 41
  • 7