限界上下文、子域和无处不在的语言答案

【问题标题】：Bounded Context, Subdomains and Ubiquitous language限界上下文、子域和无处不在的语言
【发布时间】：2013-06-11 17:32:35
【问题描述】：

a) 对于包含两个或多个子域的 BC，存在概念重叠的可能性，甚至更糟糕的是，每个子域可能会以不同的方式解释/理解相同的概念（由其中几个子域使用）。

不管，如果 BC 确实包含许多子域，它应该提供几种通用语言，每个子域一种，还是应该所有子域共享相同的通用语言？

b) 我假设当一个子域跨越多个 BC 时，每个 BC 都应该定义自己的通用语言？

谢谢

【问题讨论】：

UL 以 BC 为目标。因此，如果 BC 和子域之间存在 1-1 映射，那么每个子域都会有自己的 UL。如果一个 BC 包含多个子域，那么，是的，UL 也是共享的。
这个问题很有趣，因为无处不在确实意味着到处都是一样的，但是是的，UL 是每个 BC 的
@Asher：我为迟到的回复道歉，但我没有注意到你的回答
子域是问题空间，有界上下文是解决方案空间，但一般情况下它们应该是 1:1。对于遗留代码，每个子域有多个有界上下文是可以的，但反之则不行 - 一个有界上下文不应覆盖多个子域。

【解决方案1】：

a) 尽管每个域和子域可能有自己的语言，但 UL 专门针对 BC。 BC 尽可能多地从已经建立的领域语言中对领域和手推车进行建模。它被称为无处不在，因为它被工程师和领域专家无所不在地使用，不幸的是，对于领域语言本身来说，这通常不能说。

B) 每个 BC 都应该有自己的 UL。

当 BC 对具有重叠概念的多个（子）域进行建模时，明智的做法是考虑拆分该 BC。共享内核可用于对两个（子）域中概念上相同的重叠进行去重。

【讨论】：

我觉得每个 BC 有 1 个实体有点过度杀戮。您可以在一个 BC 中完美地拥有多个聚合根 (AG)。每个聚合都可以轻松地将实体（不是 AG）作为字段包含在其中。
我同意托尼的观点。 BC 根本不是由它的实体数量来定义的，而是由它的职责和定义来定义的。蓝皮书在这方面当然也没有过时。
@MattDavey 你把Aggregate root 和Bounded context 混淆了。这些完全不一样！并且有界上下文不应覆盖多个子域。