Java 如何确定一个对象是否应该是聚合的一部分

在我开始阅读DDD和聚合之后，我似乎试图将所有内容都整合到聚合中。几乎每一篇博客文章或教程等都使用相同的示例：订单和订单行，这对任何特定问题都没有帮助

一个物体能否独立生存意味着什么？这是不是意味着它不能在我的领域建模中独立生存，还是意味着它不能在现实世界中独立生存

我正在制作一个应用程序，用户可以跟踪他们的驾驶。比如，持续时间、距离等等

我制作了一个

StudentDriver

类，用于对人进行建模；制作了一个

DrivingLog

用于对“书”进行建模；制作了

DrivingRecords

用于对用户在驾驶时所做的每一行/记录进行建模。它包含持续时间、距离等

现在的问题是：

StudentDriver

是否应该被视为所有这些类的聚合根，并且每个操作都要经过

StudentDriver

？或者

StudentDriver

应该是根，而

DrivingLog

应该是另一个根，然后

StudentDriver

和

DrivingLog

应该相互关联

---

很高兴听到你是怎么决定的？无论是在本例中还是在一般情况下。

聚合是具有整体/部分关系的两个类之间的关系。汽车是完整的，车轮是它的一部分

在你的情况下，你可以让StudentDriver成为DrivingLog的所有者，如果它属于他的话。如果没有现有的学生，保存驾驶日志是没有意义的。因此，DrivingLog不能单独存在

---

StudentDriver应该是root用户，并了解驱动日志。但是DrivingLog不应该意识到StudentDriver（就像单向联想一样）

DDD是一本很棒的书，我也喜欢读Evans关于聚合模式的话。不过，我觉得你可能有点太过火了

据我所知，聚合模式的目的是：

当程序的每个部分都与其他部分交互时，就很难理解（和调试），因为你不能孤立地理解任何一个部分；要理解任何一部分，你必须理解一切

此外，当交互向各个方向发展时，很难找到破坏对象状态的bug，因为您必须到处寻找。如果可以修改某个对象的代码是有限的，那么就更容易保证它总是使该对象保持正确的状态

使用聚合模式，您有一个对象是聚合“根”，其他对象是由根“包含”的。只有根可以“接触”包含的对象，这减少了交互可以通过的路径数量

这是一个有用的想法，可以放在概念性的“工具箱”中，但您不需要为了使用它而使用它。与其担心“一个对象可以独立生存”意味着什么，不如看看你真正想用

StudentDriver

s和

DrivingLog

s做什么，然后想想：

如果我允许其他类直接使用

DrivingLog

s，或者如果我要求它们调用

StudentDriver

上的方法来检索或修改数据，那么该代码会更简单、更易于管理吗？想象一下，代码将以何种方式读取。在一种情况下，您可能正在从“外部”类编写

drivingLog.miliety（）

；在另一种情况下，您将编写

studentDriver.loggedMileage（）

---

DDD提出的一个最好的观点是匹配模型和实现的重要性，这甚至包括选择真正有意义的标识符（在代码中）。与此相协调，您还可以查看代码正在执行的操作，并思考：如果我思考这个操作在实际中代表什么，它是对驱动程序还是日志所做的事情？如果实际上操作是对日志簿执行的，那么不要仅仅因为要使用聚合模式，就让它使用委托给

DrivingLog

的

StudentDriver

方法。

因此聚合模式更好地应用于类，以便客户端（用户等）能更容易地理解程序中的各个部分吗？在这种情况下，drivinglog可以是drivingrecord的聚合，但是studentdriver不需要成为所有三个类的聚合器？当拥有这两个聚合根时，客户机可以轻松地理解这两个实体。这是正确的吗？或者你能试着解释一下，如果这不是你的意思吗？@Bob，对于什么时候使用某种设计模式“更好”，没有简单明了的答案。任何设计选择（例如是否使用聚合模式）都有利弊，您必须根据具体情况的细节权衡这些利弊。简单的规则，比如“如果A在现实世界中离不开B，就应该将其建模为一个集合”，没有任何帮助。不要机械地遵循这些规则，你需要理解模式的目的，并运用你的判断来判断它是否适合你正在做的事情。我对你正在做的事情的细节了解不够，无法提供关于聚合模式是否对你有帮助的意见。我得到的印象是，您编写此代码是为了练习使用聚合模式——对吗？如果是这样，为什么不尝试使用聚合和不使用聚合来编写它，在上发布两个版本，并征求对这种情况下哪种方式“更好”的意见？