我有两个 Entity Publisher 和 SocialAccount ，它们都是独立的并且具有多对多的关系。两者都是根聚合，现在我无法通过 Publisher 获得社交帐户，我想将 M To M 关系转换为 1 To M。所以我引入了另一个实体注册，将有 {PubID，SocID，CreateDate}。现在 Publisher 和 Registration 之间存在 1 对 M 的关系，Registration 和 SocialAccount 之间存在 1 对 1 的关系。所以出版商会有
列出
_Registrations {get;set;}
但是当我创建聚合边界时，Publisher 是我的根，根据聚合原则，只有根聚合将持有对另一个根聚合的引用。但这里注册持有参考。
我是不是违反了聚合原则，因为注册是关联的社会账户实体。
【问题讨论】：
您对聚合概念的使用似乎不正确。聚合中的对象实际上可以保存对其他聚合的引用。规则是外部对象不能保存对聚合中某些内容的引用。
在 Registration 对象上，您似乎创建它是为了避免一些聚合到聚合的关系。这不是你创建对象的原因。如果您的域中确实有注册，请创建它并对其建模。如果它不在您的域中，请不要添加它只是为了遍历某些路径。
添加了注册后，您说它不能包含对社交帐户的引用，因为它是发布者的一部分。这不是规则，但更重要的是，Registration 是如何突然成为 Publisher 聚合的一部分的？仅凭借 Publisher 拥有 Registration 集合？
聚合是一组对象，它们被视为一个用于维护状态和不变量的单元。关系的存在本身并不赋予总体成员资格。
但是现在看看另一边。使用社交帐户进行一对一的注册。如果我们删除了一个社交账户，那么在发布者那里注册还有意义吗？如果不是，那么注册实际上可能是 SocialAccount 聚合的一部分。这就是我们创建聚合的原因 - 以确保对象及其关系在状态更改后始终有效。如果删除 SocialAccount 的状态更改包括删除与该帐户关联的所有注册，我们希望将其包含在聚合中以执行该规则。
现在您确实违反了“聚合规则” - 您有一个从 Publisher 到对象 Registration 的外部关系，该对象是 SocialAccount 聚合的内部部分。
这些概念不仅仅是规则，它们是有原因的。您需要查看聚合的真正含义，了解规则的实际含义以及它们的真正含义，以及它们首先存在的原因。然后重新评估您的关系并相应地汇总定义。
【讨论】：
首先，我们需要一个抽象来封装模型中的引用。
AGGREGATE 是一组关联对象，我们将其视为一个单元，以便进行数据更改。
每个 AGGREGATE 都有一个根和一个边界。边界定义了 AGGREGATE 内的内容。根是聚合中包含的单个特定实体。根是 AGGREGATE 中唯一允许外部对象持有引用的成员，尽管边界内的对象可能持有对彼此的引用。根以外的实体具有本地标识，但该标识只需要在 AGGREGATE 内是可区分的，因为任何外部对象都无法从根实体的上下文中看到它。
你怎么看西弗斯？
【讨论】：