Domain driven design AggregateRoot是否应包含其他AggregateRoot的集合？

为了研究DDD，我读了这篇文章，发现了一个新的想法，作者说“不在Product类中创建‘ProductReviews’集合的理由”。因为“这两个实体之间没有真正的不变量”

Product

类中没有

ICollection

。那么，问题是

它与DDD兼容吗

这样做的优点和缺点是什么

它与DDD兼容吗

是的，将ProductReviews逻辑集合的元素分离为产品聚合之外的聚合与DDD兼容

也就是说，当以这种方式分离事物时，您通常不会尝试坚持事务性级联删除，如您链接的示例所示

这样做的优点和缺点是什么

通常有两个优点

如果对模型的两个不同部分的更改不需要同步（也就是说，您永远不需要同时更改这两个部分以保持不变），那么将这些部分建模为单独的聚合有助于使这种分离明确化（因此更容易推理，等等）

将模型分解为单独的集合支持并行工作，这意味着我们可以减少进行更改所需的协调量

如果模型的两个不同部分确实彼此分离，则可以使用完全不同的技术来存储它们

另一方面，它的缺点是，当您后来发现需要协调对两个不同聚合的更改时，事情就会变得一团糟。在这一点上，您真正拥有的是数据模型中的单个“逻辑”聚合，它在您的域模型中被分解为多个聚合，并承担协调责任。

来自cqrs.nu

我知道聚合是事务边界，但我确实需要在同一事务中以事务方式更新两个聚合。什么 我该怎么办？

你应该重新思考以下几点：

• 您的聚合边界
• 每个集合的责任
• 你可以在阅读方面或传奇故事中做些什么
• 域的实际非功能性需求
• 如果您编写了一个解决方案，其中两个或多个聚合是事务耦合的，那么您还没有理解聚合