我正在接近 DDD,并且我遇到了一个涉及相关对象层次结构的(我想很常见......)用例的麻烦。
让我们想象一下,对由许多捆绑在一起的模块组成的软件产品进行建模:
// 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”类始终是其他对象的聚合,因为它是组合树中的父级。
场景建模的另一种方法是实现“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
...
}
...
// 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 的组合自然。
关于哪种建模策略更好使用有什么建议吗?
谢谢你
我对此有一点写。如果这没有帮助,我可以详细说明。
其要点是
Entity
通常也是聚合根。在某些情况下,您可能需要一个不同的(合成)实体来充当聚合根,但我不认为具有“模块”实例集合的“软件产品”需要类似的东西,如果这确实是您的域.
另外,为了稍微扩大一下范围,请记住聚合根不应包含其他聚合根的实例,而应包含(相关聚合根的)id 的集合或表示该聚合根的值对象的集合。相关的聚合根。提及这一点以防您的
Module
可能是一个实体。