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