领域驱动设计聚合答案

【问题标题】：Domain Driven Design Aggregations领域驱动设计聚合
【发布时间】：2014-02-22 17:06:18
【问题描述】：

这个问题实际上是关于聚合，而不是聚合根。假设您有一个汽车实体。该应用程序显示每个“汽车级别”的列表（聚合）。例如，第一层可以是汽车制造商。

喜欢奥迪，大众， ...

此列表是我的“汽车”实体的聚合。

有没有一种很好的方法来处理实体的这种“聚合视图”？这是我域中的值对象吗？

我应该最终得到 4 个描述汽车的类吗？这会是很多重复的代码吗？或者我应该使用每个级别的完全“汽车”实体作为表示，但使用接口来指定您可以访问的字段？

【问题讨论】：

标签： design-patterns domain-driven-design repository-pattern

【解决方案1】：

在领域驱动设计中，聚合只能由其根访问。聚合可以由实体和值对象组成。根据您的需要，您可以为您的域提供很多功能（它们不应作为实体或值对象保留）。现在在您的示例中，您可以拥有 Car 实体（也可以是聚合的根）并具有该实体的很多特征，例如汽车制造商显然是一个价值对象。

我应该最终得到 4 个描述汽车的类吗？这会是很多重复的代码吗？或者我应该为每个级别使用完全“汽车”实体作为表示，但使用接口来指定您可以访问的字段？

正如我所提到的，您可以拥有大量的枚举、类、接口来减少代码的重复，但请记住，您最终应该持久化实体和值对象。我建议您将诸如颜色、制造、型号等汽车功能分开，并在您的聚合根中协作这些功能以保持不变。最好在实际应用中查看一些有关 DDD 的示例，获取所有 these 示例并查看 these 文章。

【讨论】：

考虑我的汽车实体有大约 200 个不同的字段（这是实体可能具有的详细程度），并且唯一的汽车实体（完全指定的汽车）到一个不太指定的汽车，称为“汽车级别 4”是缺少的电机代码。所以我的“car level4”不是一个真实的实体，而是与我的汽车实体共享 199 个字段。现在我想查询这些“car level4”的列表。但是我用什么实体来表示这个列表？
在为域建模时不要考虑数据库字段，数据库字段是存储库关注的问题。只是尝试正确建模。现在，如果您的汽车有不同的场景，您可以将汽车视为一个模块并放置不同的聚合（您称它们为级别）。我不得不再说一遍，这一切都取决于你的模型。
字段我的意思是属性，都在内存中。问题实际上是关于建模。我不确定“car_level4”是什么，它不是一辆完整的汽车，所以它不是一个实体。我应该将其表示为接口并使用汽车实体吗？我应该对汽车级别使用继承，例如 car_level1 -> car_level2 -> car_level3 -> car_level4 -> car？还是更好的构图？我应该创建新对象吗？只是想知道是否有任何好的方法来处理我需要从存储库中查询的实体的这些“部分”？/服务？。
因此，如果您的域中有多种汽车级别，您可以拥有一个基础“汽车级别”类，并且它的属性可以从基础继承其他汽车级别。根据您的需要，如果您想检索实体和值对象，可以在存储库中查询。