AggregateRoot是否应包含其他AggregateRoot的集合?

时间:2017-06-12 09:18:27

标签: domain-driven-design aggregateroot

我已经阅读了this interesting topic以研究DDD,并发现了一个新的想法,作者说“关于不在Product类中创建'ProductReviews'集合的论点” 。因为“这两个实体之间没有真正的不变量

Class diagram

ICollection<ProductReview>级内没有Product。然后,问题是

  1. 它与DDD兼容吗?
  2. 这样做的优点和缺点是什么?

2 个答案:

答案 0 :(得分:1)

  

它与DDD兼容吗?

是的,将ProductReviews逻辑集合的元素分离为Product aggregate之外的聚合与DDD兼容。

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

  

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

通常有两个优点

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

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

如果模型的两个不同部分真正相互分离,您可以使用完全不同的技术来存储它们。

另一方面,它的缺点是,当你后来发现你需要协调两个不同聚合的更改时,事情会变得混乱。那时你真正拥有的是一个单一的逻辑&#34;在您的数据模型中聚合,在您的域模型中分解为多个聚合,并具有协调的职责。

答案 1 :(得分:0)

来自cqrs.nu

  

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

     

您应该重新考虑以下事项:

     
      
  • 您的聚合边界。
  •   
  • 每个聚合的责任。
  •   
  • 你可以在阅读方面或传奇中做些什么。
  •   
  • 您域名的实际非功能性要求。
  •   
  • 如果您编写一个解决方案,其中两个或多个聚合以事务方式耦合,则您无法理解聚合。
  •