DDD - 限界上下文和部署单元

Question

我刚刚阅读了 Vaughn Vernon 的书实现领域驱动设计，我对有界上下文如何与应用程序保持一致感到有些困惑。

一个应用程序中可以有多个有界上下文吗？如果是这样，是什么决定一个上下文应该与另一个上下文一起部署还是应该作为独立单元部署？

如果我在一个应用程序（部署单元）中有多个有界上下文，并且客户端（例如 UI）同时需要来自多个上下文的信息，那么我是否应该创建一个新的应用程序服务来支持这种场景？

Answer 1

一个应用程序中可以有多个有界上下文吗？

您可以选择在单个应用程序中组织多个有界上下文，选择命名空间/文件夹之类的东西来分隔它们：

/domain /Claims /Policy.cs /Inspections /Policy.cs /Underwriting /Policy.cs

（这个“政策”例子来自 DDD Distilled）

这种方法的优点是简单，尽管它有许多缺点：

• 更有可能导致上下文之间的流血和污染 - 维护边界需要很多纪律，因为如果它们都在同一个项目中，那么仅从另一个上下文中引用对象就太容易了
• 如果多个团队在应用程序上工作，则更难以管理
• 在部署方面选择较少（可能不是问题）

如果是这样，是什么决定一个上下文应该与另一个上下文一起部署还是应该作为独立单元部署？

您必须考虑将它们放在单个应用程序中与将它们分开的优缺点。其中一些我已经在上面提到过，但还有其他事情需要考虑..

不同的上下文是否有不同的非功能性需求？即缩放，性能需求等？如果是这样，您将希望能够单独部署它们，因此它们不应成为同一应用程序的一部分。

您是否受到可以选择的技术或可以部署到的服务器的任何限制？可能存在一些限制，使迁移到更微服务风格的架构变得更加困难。

这个问题还有一个组织因素，它取决于您所在的组织类型。您的系统是否有多个团队工作？如果您在一个主要业务是基于 IT 的组​​织中工作，您通常会发现该业务已经为您做出了一些决策，通过他们根据上下文组织团队和结构（参见康威定律）的方式。这种划分是否是您真正想要/正确的是另一个问题。在其他组织中，您可能是“IT 部门”或更一般的部门，在这种情况下，您可能对如何建模和组织事物有更多的控制权。

如果我在一个应用程序（部署单元）中有多个有界上下文，并且客户端（例如 UI）同时需要来自多个上下文的信息，那么我是否应该创建一个新的应用程序服务来支持这种场景？

正如@plalx 在评论中提到的，您可以在客户端或服务器端进行此聚合。想象一个包含 3 个小部件的页面，其中每个小部件对不同的上下文进行 AJAX 调用（如果将它们分开）并以这种方式组成 UI。或者，您可以聚合服务器端，即为所讨论的 UI 设置某种读取模型。