聚合DDD中的对象，这是潜在的聚合吗？

Question

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

现在，从我已阅读的内容中，聚合对象是唯一具有存储库的对象，并且，如果移除了附加到数据库中的问题，那么QuestionLog对象不应该在我的系统中，所以我认为Question将是聚合根。

这样做是否有意义？

如果我想要用户提交的QuestionLogs列表怎么办？ 然后，我是否将创建一个JPQL来检索用户已提交的所有QuestionLog，或者这会破坏预期的方式？ 我是否应该改为检索由该特定用户附加了QuestionLogs的问题列表，然后遍历所有问题并显示每个QuestionLog的属性？

因为必须允许在Question类之外使用QuestionLog对象？ 我对限制和改变方式感到困惑。

Answer 1

由于QuestionLog没有相应的Question没有意义，所以您是对的-它不是聚合根。

与QuestionLog所有操作均应通过Question汇总进行。

如果要为用户提供QuestionLog列表，则需要在Question集合上定义GetQuestionLogsForUser(user aUser)方法。 你不必以获取用户的所有问题，但控制访问QuestionLog通过聚合秒。

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

Answer 2

正如Oded所指出的，与QuestionLog实例相关的所有行为都应通过Question集合进行。 但是，对于查询，您具有更大的灵活性。 您可以在Question聚合上有一个方法，该方法返回适合给定查询的QuestionLog实例，但是有时，要求可能会使这种方法不切实际。 在这种情况下，您可以使用读取模型模式，并拥有一个专用于根据问题ID和某些过滤器来检索问题日志的存储库。 这使您可以利用数据库进行查询。 的确，与问题相关的某些逻辑将“泄漏”到汇总之外，这是一个公平的权衡，尤其是如果所有行为都与汇总保持一致的话。

考虑总体边界时，您不能完全忘记技术上的顾虑。 可能一个Question可能具有大量关联的问题日志。 在这种情况下，对于返回小子集的查询，将整个聚合加载到内存中是不切实际的。 您甚至可以考虑使QuestionLog本身成为聚合。 看看Vaughn Vernon的“有效的骨料设计 ”可以对此主题进行深入的讨论。