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