我应该为 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 有不同的方法。

这个问题（和答案）很好地总结了这个问题：

一种方法是将整个应用程序视为 BC，另一种方法是仅将域逻辑视为 BC。

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

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

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

案例二：BC表现为领域逻辑库

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

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