假设我有一个带有 2 个聚合根的“目录”有界上下文。公司和个人。公司有一个子实体“职位”的集合,其中包含一个人的 ID 以及一些额外的价值数据。
都好。
现在我们去添加一个带有聚合根 JobAriticle 的“Article”有界上下文。这需要一个从公司职位映射的联系人值对象。
所以知道你应该只引用聚合根我应该怎么做?假设公司与职位的关系存在不变量,所以我不想拆分汇总。是否可以通过公司和职位 ID 通过反腐败层映射职位?或者我是否需要尝试拆分公司集合。
假设我有一个带有 2 个聚合根的“目录”有界上下文。公司和个人。公司有一个子实体“职位”的集合,其中包含一个人的 ID 以及一些额外的价值数据。
都好。
现在我们去添加一个带有聚合根 JobAriticle 的“Article”有界上下文。这需要一个从公司职位映射的联系人值对象。
所以知道你应该只引用聚合根我应该怎么做?假设公司与职位的关系存在不变量,所以我不想拆分汇总。是否可以通过公司和职位 ID 通过反腐败层映射职位?或者我是否需要尝试拆分公司集合。
如果Position
在“文章”有界上下文的通用语言中是一个有意义的概念,那么Position
应该是“文章”有界上下文中的 ValueObject 或实体。
如果您说这Contact
是“文章”有界上下文中有意义的概念,但它需要以某种方式与Position
“目录”有界上下文中的 a 相关联,那么您需要考虑这种关联的目的是什么:
JobArticle
?Position
和 a之间保持同步Contact
?如果您需要在创建关联联系人之前验证 a 是否Position
存在,那么 Position 在 Article 上下文的职责中隐含地扮演角色 - 所以我很想Position
在 Article 上下文中创建一个新实体并使其保持同步。
无论哪种方式,要将 Article 上下文中的某些内容与 Directory 上下文中的相应实体相关联,您可以在名为“Article”的上下文中创建一个 ValueObject,PositionCorrelation
它具有两个属性:
聚合应仅引用其他聚合根的规则并不意味着您也不能提供用于识别聚合内实体的信息。这只是意味着如果你想与其他实体交互,你应该通过聚合根来进行,这意味着你至少必须有聚合根 Id。如果您随后使用本地 ID 要求公司对其某个职位做某事,那很好。
但是 - 请注意,通过遵循这种方法,您将术语“位置”引入“文章”有界上下文中,如果“位置”一词在“文章”上下文中表示其他含义,则可能会引入名称冲突 - 例如也许它意味着文章中的位置(段落编号等)。如果是这种情况,您需要仔细考虑如何调用跨上下文标识符。
一种方法可能是,如果Position
与 有一对一的映射Contact
,那么您的两个属性可以是:
当在上下文之间集成时在反腐败层 (ACL) 保持同步时,将 CompanyContactId 和 PositionId(公司内的本地)值定义为同义词。这使每个 UL 保持内部一致,并在 ACL 中定义两者之间的相关性。