我刚刚读了Vaughn Vernon的书《实现领域驱动设计》，我对有界上下文如何与应用程序对齐有点困惑。
在一个应用程序中可以有几个有界上下文吗?如果是这样，是什么决定一个上下文应该与另一个上下文一起部署，还是应该作为一个独立的单元部署?
如果我在一个应用程序(部署单元)中有多个有界上下文，并且客户机(例如UI)同时需要来自多个上下文的信息，那么我应该创建一个新的应用程序服务来支持这个场景吗?
在一个应用程序中可以有几个有界上下文吗?
您可以选择在单个应用程序中组织多个有界上下文，选择名称空间/文件夹之类的东西来分隔它们:
/domain
/Claims
/Policy.cs
/Inspections
/Policy.cs
/Underwriting
/Policy.cs
(此"策略"示例来自DDD蒸馏)
这种方法的优点是简单，尽管它有许多缺点:
- 更有可能导致上下文之间的流血和污染-需要大量的纪律来维护边界，因为如果它们都在同一个项目中，那么很容易从另一个上下文引用对象
- 如果多个团队在应用程序上工作，则更难管理
- 部署时选择较少(可能不是问题)
如果是，是什么决定一个上下文应该与另一个上下文一起部署，还是应该作为一个独立的单元部署?
您必须考虑将它们放在单个应用程序中与将它们分开的优点和缺点。其中一些我已经在上面提到了，但还有其他事情需要考虑。
不同的上下文是否有不同的非功能需求?例如，可伸缩性、性能需求等?如果是这样，您将希望能够单独部署它们，因此它们不应该是同一个应用程序的一部分。
您是否受到可以选择的技术或可以部署到的服务器的限制?可能存在一些限制，使得迁移到更微服务风格的架构更加困难。
这个问题还有一个组织因素，这取决于你所在的组织类型。您是否有多个团队在您的系统上工作?如果你在一个主要业务是基于IT的组织中工作，你会经常发现业务已经为你做了一些决定，通过他们组织团队和结构(见康威定律)与环境相一致的方式。这种划分是否是你真正想要的/正确的是另一个问题。在其他组织中，您可能是"IT部门"或更一般的部门，在这种情况下，您可能对如何建模和组织事物有更多的控制权。
如果我在一个应用程序(部署单元)中有多个有界上下文，并且客户机(例如UI)同时需要来自多个上下文的信息，那么我应该创建一个新的应用程序服务来支持这个场景吗?
正如@plalx在评论中提到的，您可以在客户端或服务器端执行此聚合。想象一个有3个小部件的页面，其中每个小部件对不同的上下文进行AJAX调用(如果将它们分开)，并以这种方式组合UI。或者，您可以聚合服务器端，即为正在讨论的UI提供某种读模型。