DDD 中的聚合对象，这是一个潜在的聚合吗？答案

【问题标题】：Aggregate objects in DDD, is this a potential aggregate?DDD 中的聚合对象，这是一个潜在的聚合吗？
【发布时间】：2012-10-26 09:02:03
【问题描述】：

我有两个实体 Question 和 QuestionLog。问题显然代表一个问题，而 QuestionLog 代表用户可以报告特定问题的实体。例如，如果问题是错误的，质量差等。

现在从我所阅读的内容来看，聚合对象是唯一具有存储库的对象，并且由于 QuestionLog 对象不应该在我的系统中，如果它所附加的问题被删除，我认为 Question 将是聚合根。

这是一个有意义的场景吗？

如果我想要用户提交的 QuestionLogs 列表怎么办？然后我会制作一个 JPQL 来检索用户提交的所有 QuestionLog，还是会破坏它的预期方式？我是否应该检索一个问题列表，该列表具有该特定用户附加的 QuestionLogs，然后遍历所有问题并显示每个 QuestionLog 的属性？

因为必须允许在 Question 类之外使用 QuestionLog 对象？我对限制和它的方式有点困惑。

【问题讨论】：

顺便说一句，聚合不是对象，它是相关对象的集合（将其视为云）。聚合根是针对特定情况“代表”聚合的对象。

标签： java jakarta-ee domain-driven-design

【解决方案1】：

由于QuestionLog 没有对应的Question 就没有意义，你是对的——它不是聚合根。

与QuestionLog 相关的所有操作都应通过Question 聚合。

如果您想要一个用户的QuestionLog 列表，您需要在Question 聚合上定义GetQuestionLogsForUser(user aUser) 方法。您必须获取用户的所有问题，但通过聚合控制对QuestionLogs 的访问。

您可以使用聚合根之外的QuestionLog 对象，但对其进行的任何操作都应通过聚合根完成，尤其是持久性问题。

【讨论】：

那么在 getQuestionLogsForUser(User user) 中，您会返回该特定用户的 Questions 或 QuestionLogs 列表吗？你还说如果我想更新一个 QuestionLog 对象我需要说 myQuestion.updateQuestionLog(...); ?但是，只要通过问题进入存储库，我就可以在代码中的任何地方使用 QuestionLog？
@Dude - 我认为函数的命名很清楚。您返回QuestionLog 的集合。是的，如果您要更新QuestionLog，您需要通过聚合来完成。对它的更新应该通过聚合，以便聚合可以保存所有不变量。
应该 QuestionLog 也有对 Question 的引用吗？或者 Questions 引用 QuestionLogs 就足够了？
@Dude - 这是一个我无法回答的建模问题。如果您需要从QuestionLog 导航回Question，那么您可能需要这个。如果没有，你不会。
好的，所以与问题无关。那是公平的。只是想知道是否有任何限制。所以底线是您可以正常使用作为聚合一部分的实体（实例化，从聚合根方法返回它们等），但与存储库的所有交互都必须通过聚合根对象。所有属于聚合根但没有自己的存储库的对象的所有发现都是通过聚合根完成的？

【解决方案2】：

正如 Oded 所指出的，与QuestionLog 实例相关的所有行为都应该通过Question 聚合。但是，对于查询，您有更多的灵活性。您可以在 Question 聚合上有一个方法，该方法返回适合给定查询的 QuestionLog 实例，但有时，要求可能使这种方法不切实际。在这种情况下，您可以使用read-model pattern 并拥有一个专门用于根据问题 ID 和一些过滤器检索问题日志的存储库。这允许您利用数据库进行查询。虽然确实如此，但与问题相关的一些逻辑会“泄漏”到聚合之外，这是一个公平的权衡，特别是如果所有行为都保留在聚合中。

在考虑聚合边界时，您不能完全忘记技术问题。 Question 可能会包含大量相关的问题日志。在这种情况下，将整个聚合加载到内存中以进行返回小子集的查询是不切实际的。您甚至可以考虑将QuestionLog 本身设为聚合。请查看 Effective Aggregate Design by Vaughn Vernon 以深入讨论此主题。

【讨论】：