两个有界上下文之间的身份参照

Question

我希望围绕DDDCQRS原则获得最佳实践，以处理绑定上下文之间的关系。

我们有两个BC物业管理上下文和租户门户上下文。我们有 家装骨料 在Tenant Portal的背景下，它的运行完全独立于Tenant Portal。财产总额 在物业管理上下文中，我们发现有必要在初始事件中存储其他BC的PropertyId。然而，在创建 "家 "时，我们发现需要在初始事件中存储来自其他BC的PropertyId作为查询。

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

在其他有界上下文中引用集合根被认为是可以接受的吗？

如果不推荐，那么更好的选择是否是通过尝试使用特定上下文的语言，如LookUpCode或ExternalReferenceCode，来故意模糊这种关系。即使，有一个隐含的理解，这其实是PropertyId，近期不太可能是其他东西。

对于类似的问题，我看到的两种不同的相反建议是。

• DDD--使用Doctrine 2在有界上下文之间进行关联映射。 - "在另一个业务连续性中引用一个实体的正确方式是通过ID"
• - "如果他们每个人都有一个CustomerId，那么就违背了一个上下文的概念和语言不泄露给其他上下文的目的。"

Answer 1

你引用的建议其实并不矛盾。

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

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

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

PropertyRef在PropertyMgmt中是一个实体ID，这个事实与TenantPortal无关。