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

Question

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

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

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

如果我想要用户提交的QuestionLog列表怎么办？然后，我会创建一个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个实例，但有时，要求可能会使此方法不切实际。在这种情况下，您可以使用read-model pattern并拥有专用于根据问题ID和某些过滤器检索问题日志的存储库。这允许您利用数据库进行查询。虽然确实如此，但与问题相关的一些逻辑会在汇总之外“泄漏”，这是一个公平的权衡，特别是如果所有行为与汇总一起保留。

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