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

Question

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

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

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

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

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

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

• DDD - Association mapping between bounded contexts using Doctrine 2 - “在另一个 BC 中引用实体的正确方法是通过 ID”
• DDD - aggregate root identity usage across bounded context bounderies - “如果他们每个人都有一个 CustomerId，那么它违背了一个上下文的概念和语言不泄漏到其他上下文的目的。”

Answer 1

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

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

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

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

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