DDD：实体也可以是聚合吗？

Question

我正在接近 DDD，并且我遇到了一个涉及相关对象层次结构的（我想很常见......）用例的麻烦。

让我们想象一下，对由许多捆绑在一起的模块组成的软件产品进行建模：

场景 1：聚合就是实体本身

// The 'Product' entity
class Product {
    
   String version;      // Identity
   Set<Module> modules; // Entities
   Date releasedOn;     // VO
   Author releasedBy;   // VO
   ...
   ...

}

// The 'Module' Entity
class Module {
  
   ModuleVersion version;   // Identity
   String name;
   ModuleMetadata metadata; // VO
   ...

}

首先，我将 “Product” 类识别为 Entity，因为在我的上下文中，它具有身份（版本）。 但“Product”类始终是其他对象的聚合，因为它是组合树中的父级。

• 在某些情况下，实体也充当聚合，这样说是否正确？
• 如果是，在这种情况下，充当聚合的实体是聚合根本身是否正确？

场景 2：引入物理类来对充当简单包装器的聚合进行建模

场景建模的另一种方法是实现“ProductAggregate”来“物理”模拟聚合，但说实话，我看不出它能带来什么好处：

// The 'Product' aggregate. 
// Which benefit of introducing this wrapper?
class ProductAggregate {
    
   Product product; 

}

// The 'Product' entity
class Product {
    
   String version;      // Identity
   Set<Module> modules; // Entities
   Date releasedOn;     // VO
   Author releasedBy;   // VO
   ...

}

...

场景 3：引入物理类来对聚合进行建模，将“模块”移动到聚合

// The 'Product' aggregate
class ProductAggregate {
    
   Product product;
   Set<Module> modules;
   ...

}

// The 'Product' entity (without modules)
class Product {
    
   String version;      // Identity
   Date releasedOn;     // VO
   Author releasedBy;   // VO
   ...

}

在这种情况下，“ProductAggregate”类是有意义的，并且整体模型似乎更好地遵循 DDD 原则。无论如何，以我思考现实世界的方式，使用案例 2 的组合不如使用案例 1 的组合自然。

关于哪种建模策略更好使用有什么建议吗？

谢谢你

Answer 1

我对此有一点写。如果这没有帮助，我可以详细说明。

其要点是

Entity

通常也是聚合根。在某些情况下，您可能需要一个不同的（合成）实体来充当聚合根，但我不认为具有“模块”实例集合的“软件产品”需要类似的东西，如果这确实是您的域.

另外，为了稍微扩大一下范围，请记住聚合根不应包含其他聚合根的实例，而应包含（相关聚合根的）id 的集合或表示该聚合根的值对象的集合。相关的聚合根。提及这一点以防您的

Module

可能是一个实体。