在我当前的项目（电子商务网站）中，我们有不同的限界上下文，例如：结算过程中的计费、交付或付款。
除此之外，根据客户购买的商品，结帐流程也会有所不同。因此，根据她购物车的内容，结帐过程中的步骤数可能会有所不同，否则我们不会/不会询问她某些信息。
那么应该为每种不同类型的结账流程创建不同的限界上下文吗？
例如，订单聚合根会根据结帐流程而有所不同 EticketsOrder（在这种情况下，我们不需要送货地址，因此我们不会向用户询问） 票务地址
ClothesOrder（在这种情况下，我们需要一个送货地址，并且在结帐过程中将有一个额外的步骤来获得这个） 衣服 BillingAddress DeliveryAddress
这种分离意味着创建两个不同的域实体，即使它们具有相似的属性。
模拟此类问题的最佳方法是什么？如何找到上下文边界？
【问题讨论】：
标签： domain-driven-design aggregate bounded-contexts
有界上下文主要是语言边界。引自蓝皮书（突出显示的关键部分）：
有界上下文界定了特定模型的适用性，因此 团队成员对已经发生的事情有清晰和共同的理解 保持一致以及它与其他上下文的关系。在那之内 CONTEXT，努力保持模型逻辑上的统一，但不要担心 关于这些范围之外的适用性。在其他上下文中，其他 模型适用，但在术语、概念和规则方面存在差异， 以及通用语言的方言。
要问的一个问题是，创建的不同类型的订单是完全不同的聚合，还是它们都是具有不同值的订单聚合。不管它们是如何创建的，是否需要将顺序作为一个整体来考虑？我已经构建并使用过电子商务系统，其中不同类型的订单都被建模为相同聚合的实例，只是具有不同的设置并且没有语言问题。另一方面，您域中的顺序可能不同，足以保证不同的上下文。
我经常从functional cohesion 的角度考虑BC 边界。如果你把订单分成两个BC，它们之间会不会有高度的耦合？如果是这样，这可能表明它们应该合并为一个 BC。另一方面，如果 BC 交互的唯一位置是为了报告目的，则无需将它们合并。
【讨论】：
您似乎错过了一个有界上下文。当这种情况发生时，人们倾向于尝试将功能融入现有的 BC。同样的事情也发生在聚合根上。如果某些内容看起来很笨拙或没有意义，请尝试看看您是否错过了某些内容。
在您的示例中，我建议使用 Shopping BC（或任何有意义的名称）。您正在尝试将您的结帐流程融入您的 Order BC。您的 Shopping BC 将负责收集所有数据，然后将其传送到相关部分。
选择的产品类型将决定是否需要实物交付。
希望对您有所帮助。
【讨论】：