.net - 我应该在 DDD .NET 中为有界上下文使用单独的项目吗？

Question

我们正在讨论如何实现领域驱动设计。

为每个有界上下文使用单独的项目是否有任何直接的缺点？

欢迎对我们的方法提出任何想法和建议。

所以它看起来像:

- 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

我们正在考虑使一些有界上下文只能通过 Web 服务访问，以允许可能获得大量流量的区域的可扩展性。

Answer 1

这个问题的答案并不像最初看起来那样直截了当。这是因为集成 BC 有不同的方法。

This question (and answer)很好地总结了这个问题:

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

要回答您的问题，我们显然必须区分两者。

案例1:BC表现为整个应用程序

在这种情况下，您通常每个应用程序都有一个开发团队(以及扩展的 BC)。 因此，合适的 VS 解决方案和项目设置是为每个应用程序创建一个解决方案，并根据逻辑分层构建项目。

案例 2:BC 表现为领域逻辑库

在这里，如果整个应用程序不是太大，将所有内容放在一个解决方案中可能是有意义的。否则，根据需要将支持 BC 提取到他们自己的解决方案中。这通常是由团队组织驱动的。

将此应用于您的案例，我认为您的建议是一个很好的起点。如果解决方案变得太大，您可以稍后将用户内容取出并将其移动到专用解决方案中。 这里重要的是要有明确定义的 BC 边界和接口(interface)。有了它，以后移动东西就更容易了。