design-patterns - 两个有界上下文之间的身份引用

Question

我希望获得有关处理有界上下文之间关系的 DDD/CQRS 原则的最佳实践。

我们有两个 BC 属性管理上下文和租户门户上下文。我们在租户门户上下文中有Home 聚合，它的运行完全独立于物业管理上下文中的Property 聚合。但是，在创建 Home 时，我们发现需要将来自其他 BC 的 PropertyId 存储在初始事件中作为查找。

我最初认为不鼓励跨 BC 引用事件标识。然而，我团队中的某个人对这种观点提出了质疑，我正在努力寻找支持这两种论点的资源。

在其他有界上下文中引用聚合根是否可以接受？

如果不建议这样做，更好的选择是通过尝试使用特定于上下文的语言（例如 LookUpCode 或 ExternalReferenceCode）来有意地模糊关系。尽管如此，有一个隐含的理解，即这实际上是 PropertyId，在不久的将来不太可能是其他任何东西。

我对类似问题看到的两个不同的相反建议是：

• DDD - 使用 Doctrine 2 的有界上下文之间的关联映射- “在另一个 BC 中引用实体的正确方法是通过 ID”
• DDD - 跨有界上下文边界聚合根身份使用- “如果它们每个都有一个 CustomerId，那么它违背了一个上下文的概念和语言不泄漏到其他上下文的目的。”

标签： design-patternsdomain-driven-designcqrsevent-driven-designbounded-contexts

Answer 1

您引用的建议实际上并不矛盾。

使用外部 ID 来引用在其他上下文中定义的实体是合理的，但是：

• 如果 BC 使用外国 ID，那么它也不应该将其用作自己实体的 ID；实际上
• 假设内部实体和外部实体之间存在 1-1 对应关系通常不是一个好主意；和
• 假设外部 ID 根本不是实体 ID，这甚至不是一个好主意。它是与外部上下文交互所需的 ID。它是根据您在这些交互中可以用它做什么来定义的，并且不应有其他用途。

因此，例如，如果 TenantPortal 需要执行某些操作或从 PropertyMgmt 获取某些信息，则 TenantPortal.Home 可以包含一个 PropertyRef，它可以用来执行这些操作或获取该信息。它没有其他用途，也不应该是 TenantPortal 中任何内容的（一部分）ID。

PropertyRef 是 PropertyMgmt 中的实体 ID 这一事实与 TenantPortal 无关。