Should I use separate projects for bounded contexts in DDD .NET?

Question

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.

Answer 1

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.

Answer 2

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...