有界背景找到了界限？

Question

在我目前的项目（电子商务网站）中，我们在结帐过程中有不同的有界背景，如：结算，投放或付款。

除此之外，根据客户的购买要求，结账流程也会有所不同。因此，根据购物车的内容，结帐过程中的步骤数可能会有所不同，或者我们不会/将要求她提供某些信息。

那么应该为每种不同类型的结账流程创建不同的有界上下文吗？

例如，Order聚合根将根据结帐流程而有所不同 EticketsOrder（在此上下文中我们不需要送货地址，因此我们不会向用户询问）  Ticket BillingAddress

ClothesOrder（在这种情况下，我们需要一个送货地址，结账过程中还会有一个额外的步骤来获取此信息） 衣服BillingAddress DeliveryAddress

这种分离意味着创建两个不同的域实体，即使它们具有相似的属性。

模拟此类问题的最佳方法是什么？如何找到上下文边界？

Answer 1

有界语境主要是语言边界。蓝皮书的引用（突出显示的关键部分）：

  

A BOUNDED CONTEXT界定了特定模型的适用性   团队成员对所拥有的内容有清晰的共识   保持一致以及它与其他背景的关系。在那之内   背景，努力使模型在逻辑上统一，但不要担心   关于在这些范围之外的适用性。在其他背景中，其他   模型适用于术语，概念和规则的差异，   和UBIQUITOUS LANGUAGE的方言。

要问的问题是，创建的不同类型的订单是完全不同的聚合，还是所有订单聚合都具有不同的值。无论如何创建订单，是否需要考虑整体订单？我已经构建并使用电子商务系统，其中不同类型的订单都被建模为相同聚合的实例，只是具有不同的设置并且没有语言问题。另一方面，您域中的订单可能不同，足以保证不同的上下文。

我经常从functional cohesion的角度考虑BC边界。如果将订单分成两个BC，它们之间会有很高的耦合吗？如果是这样，那可能表明他们应该合并为一个BC。另一方面，如果BCs互动的唯一地方是出于报告目的，则无需将它们合并。

Answer 2

好像你可能错过了有限的背景。当发生这种情况时，人们倾向于尝试将功能融入现有的BC中。聚合根也会发生同样的事情。如果某些事情看起来很笨拙或没有意义，那就试着看看你是否错过了什么。

在你的例子中，我会建议购物BC（或任何名称有意义）。您正在尝试将结帐流程纳入您的订单BC。您的购物BC将负责收集所有数据，然后将其传递到相关部分。

所选的产品类型将决定是否需要实物交付。

希望有所帮助。