我刚刚阅读了 Vaughn Vernon 的《实现领域驱动设计》一书，我对限界上下文如何与应用程序保持一致感到有些困惑。
一个应用程序中可以有多个有界上下文吗？如果是这样，是什么决定了一个上下文应该与另一个上下文一起部署，还是应该作为一个独立单元部署？
如果我在一个应用程序（部署单元）中有多个有界上下文，并且客户端（例如 UI）同时需要来自多个上下文的信息，我是否应该创建一个新的应用程序服务以支持这种情况?
【问题讨论】：
一个应用程序中可以有多个有界上下文吗？
您可以选择在单个应用程序中组织多个有界上下文，选择命名空间/文件夹之类的东西来分隔它们：
/domain
/Claims
/Policy.cs
/Inspections
/Policy.cs
/Underwriting
/Policy.cs
（这个“策略”示例来自 DDD Distilled）
这种方法的优点是简单，尽管它有许多缺点：
如果是这样，是什么决定了一个上下文应该与另一个上下文一起部署，还是应该作为一个独立单元部署？
您必须考虑将它们放在单个应用程序中与将它们分开的优点和缺点。其中一些我已经在上面提到过，但还有其他事情需要考虑..
不同的上下文是否有不同的非功能性需求？即缩放，性能需求等？如果是这样，您将希望能够单独部署它们，因此它们不应该是同一应用程序的一部分。
您是否受到您可以选择的技术或可以部署到的服务器的限制？可能存在一些限制，使得迁移到更微服务风格的架构变得更加困难。
这个问题还有一个组织元素，这取决于您所在的组织类型。您是否有多个团队在您的系统上工作？如果您在一个主要业务是基于 IT 的组织中工作，您通常会发现该业务已经为您做出了一些决定，因为他们组织了团队和结构（请参阅康威定律）与上下文保持一致。这种划分是否是您真正想要/正确的，是另一个问题。在其他组织中，您可能是“IT 部门”或更一般的东西，在这种情况下，您可能对如何建模和组织事物有更多的控制权。
如果我在一个应用程序（部署单元）中有多个有界上下文，并且客户端（例如 UI）同时需要来自多个上下文的信息，我是否应该创建一个新的应用程序服务以支持这种情况?
正如@plalx 在 cmets 中提到的，您可以在客户端或服务器端进行此聚合。想象一个包含 3 个小部件的页面，其中每个小部件对不同的上下文进行 AJAX 调用（如果将它们拆分）并以这种方式组成 UI。或者，您可以聚合服务器端，即为相关 UI 提供某种读取模型。
【讨论】：