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