DDD - 由于聚合数据不同而导致多个有界上下文？答案

【问题标题】：DDD - Multiple Bounded Contexts because of differing aggregate data?DDD - 由于聚合数据不同而导致多个有界上下文？
【发布时间】：2018-12-11 07:03:36
【问题描述】：

我们尝试将我们的领域拆分为有界上下文，以实现模块化应用程序设计/架构。

我们进行了一次启发性的 EventSorming 会议，这对我们识别有界上下文及其聚合有很大帮助。研讨会结束后，每个参与者都同意我们确定的有界上下文。

尽管如此，我们仍然感到不舒服，因为我们担心我们的有限上下文仍然太大。 EventStomring 专注于领域事件/流程，这是我们用来识别有界上下文的主要构建块。

我们还确定了诸如“合同”之类的聚合。每个合同几乎都遵循相同的流程，但这些合同包含的数据量可能会有很大差异。有非常简单的合同类型和包含大量附加数据和附件的合同类型。

仅仅因为聚合的数据更复杂而声明另一个有界上下文是否有意义？

这两种方法都有其缺点：

在一个有界上下文中实现所有合约类型可能会导致代码中出现大量 if 语句以处理不同的数据。
仅因为某些数据不同，提取新的有界上下文可能会导致大量重复代码。

任何建议/最佳实践如何处理？

【问题讨论】：

不同类型的合同是否由不同的运营团队处理？如果是，他们是否使用不同的词汇来描述他们的工作？
不一定。问题是我们的软件只是充当这些合同的“代理”。合同由第三方制定。目前，我们试图将所有这些不同的合约映射到一个结构（模型）来统治它们，这似乎不是一个好主意。 ;-) 因此我们想要拆分事物，但我们不确定拆分应该走多远。

标签： domain-driven-design aggregate bounded-contexts domain-events

【解决方案1】：

...域事件/进程，这是我们使用的主要构建块识别我们的有界上下文

BCs 不被进程识别，BCs 与语言有关。每个 BC 都有自己的通用语言 (UL)。 BC 是概念具有意义的上下文。无论如何，BC属于解决方案空间。首先，您应该探索域（问题空间）并将其拆分为子域，提取核心域。然后为每个子域建模。 BC 是模型所在的上下文。理想情况下，子域和 BC 之间的关系是 1:1。

发现子域的过程是迭代的，当您更了解该域并与专家交谈时，您会发现它们。当你发现一个词可能有不同的意思时，或者当两个不同的词有相同的意思时，这意味着你正在跨越 BC 之间的边界。

因此，子域识别不是关于流程，而是关于概念和 UL。

仅仅因为聚合的数据更复杂？

不，您不应该仅仅因为聚合很复杂就任意创建 BC。 BC 基于 UL。

任何建议/最佳实践如何处理？

您应该通过与领域专家交谈来了解有关该领域（合同、类型等）的更多信息，并研究您的聚合（事务一致性）...无论如何，如果您将聚合拆分为其他聚合，这并不意味着它们属于不同的BC，它们仍然可以属于同一个BC。一个 BC 可以有多个聚合。这完全取决于您的具体域。

【讨论】：

【解决方案2】：

有界上下文与 if 语句关系不大，所以我不确定你的意思。

有界上下文是一组语义上封闭的业务功能。基本上，如果您的有界上下文可以完全隔离地执行其功能，即使其他上下文不可用，它也可以很好地定义。

除此之外，您可以在上下文中进行任何设计。我觉得 if 语句的数量更多地取决于您的类/代码设计，例如您是否正确使用多态性、接口等。

但是，就您的观点而言：您不需要第一次就让一切都完美无缺。如果您确定了一些有效的上下文，那么您已经完成了困难的部分。如果可以进一步划分任何上下文，则可能会在以后随时发生，而对其他人几乎没有影响（因为上下文或多或少是孤立的）。

【讨论】：

感谢您的回答。所以你认为首先将太多的东西放在一个有界的上下文中比把可能属于一起的东西分开要好？
类似的。我要说的是：迭代！如果您不确定并且没有立即需要（没有架构限制或要求），那么现在不要这样做，推迟这个决定。如果你觉得对于一个环境来说东西太多了，比如一个团队需要处理太多的功能，那么你现在就需要拆分。等到一个好的、立即理由可见。在那之前，要有一个好的内部设计来摆脱你的 if 语句。

【解决方案3】：

没有针对不同类型合同的特定业务团队
没有专门针对特定类型合同的开发团队
所有合同都使用相同的通用语言
每份合同几乎都遵循相同的流程

对我来说，这些迹象表明所有合同都属于同一个业务子域，并且理想情况下应该在同一个限界上下文中 - 除非遗留系统或第三方系统强迫您这样做。

【讨论】：