DDD：有界上下文——在另一个有界上下文中引用关注点的域实体答案

【问题标题】：DDD: bounded contexts - domain entities that reference concerns in another bounded contextDDD：有界上下文——在另一个有界上下文中引用关注点的域实体
【发布时间】：2011-10-03 13:28:43
【问题描述】：

我对如何定义它们之间存在共同关注点的有界上下文以及如何用域实体表示这一点感到困惑。

例如：客户在客户上下文中有许多产品一家公司拥有和公司上下文中的产品列表

因此，客户通过客户上下文进行管理，公司通过公司上下文进行管理

鉴于上下文位于不同的模块中。

如果我想在产品中提供公司的详细地址，应该如何处理？

我是在包含客户的模块中引用包含公司上下文的模块，还是在客户上下文中创建一个公司实体，专门用于与客户交互时使用？

谢谢

【问题讨论】：

标签： domain-driven-design entities bounded-contexts

【解决方案1】：

您可以在不同的有界上下文中对同一实体进行不同的表示。 Company BC 的公司可能与User BC 的公司有很大不同。他们所要分享的只是某种相关 ID。

【讨论】：

您是否根据使用的上下文对实体进行了不同的命名？例如。在公司 BC 中将其称为 Company，在用户 BC 中称为 Organization？这是否违背了 UL 的建立？或者 UL 是否仅适用于上下文，即使实体跨越上下文？
UL 应该适用于 BC，这是 Evans 本人所说的。
对于那些想知道的人：UL = UbiquitousLanguage
是的，你会有某种重复。但最好将这些东西分开，以便它们可以独立进化。否则你又回到了单体时代，一切都与某种“域”库耦合，这种库不断增长到不再可维护的地步。
无论如何，我们今天编写的 99% 的代码只是将数据从一层传递到另一层，这也可以视为重复工作。但不知何故，每个人都很好

【解决方案2】：

这也是我们在项目中的处理方式。

在一个有界上下文中，我们将合约用作聚合根，而在另一个有界上下文中，我们将合约用作值对象/实体

在第一个模块/BC 中，我们有一个包含很多行为的大型合约类，而在第二个模块/BC 中，我们有另一个合约类，它只包含一些带有私有设置器的属性。

这样甚至可以在 SOA 设计中将 2 个 BC 分离成单独的服务组合。

【讨论】：