我有两个实体 Question 和 QuestionLog。问题显然代表一个问题，而 QuestionLog 代表用户可能报告特定问题的实体。例如，如果问题是错误的，质量差等。
现在从我所阅读的内容来看，聚合对象是唯一具有存储库的对象，并且由于 QuestionLog 对象不应该在我的系统中，如果它所附加的问题被删除，我认为 Question 将是聚合根。
这是一个有意义的场景吗？
如果我想要用户提交的 QuestionLogs 列表怎么办？然后我会制作一个 JPQL 来检索用户提交的所有 QuestionLog，还是会破坏它的预期方式？我是否应该检索该特定用户附加了 QuestionLogs 的问题列表，然后遍历所有问题并显示每个 QuestionLog 的属性？
因为必须允许在 Question 类之外使用 QuestionLog 对象？我对限制和它的方式有点困惑。
由于QuestionLog没有相应的 没有意义Question，所以你是对的 - 它不是聚合根。
所有与之相关的操作都QuestionLog应该通过Question聚合。
如果你想要一个QuestionLog用户的列表，你需要在Question聚合上定义一个GetQuestionLogsForUser(user aUser)方法。您不必为用户获取所有问题，而是QuestionLog通过聚合控制对 s 的访问。
您可以在聚合根之外使用QuestionLog对象，但对其进行的任何操作都应通过聚合根完成，尤其是持久性问题。
正如 Oded 所指出的，与实例相关的所有行为QuestionLog都应该通过Question聚合。但是，对于查询，您有更多的灵活性。您可以在Question聚合上有一个方法，该方法返回QuestionLog适用于给定查询的实例，但有时，需求可能会使这种方法不切实际。在这种情况下，您可以使用读取模型模式并拥有一个专门用于根据问题 ID 和一些过滤器检索问题日志的存储库。这允许您利用数据库进行查询。虽然这是真的，但与问题相关的一些逻辑会“泄漏”到聚合之外，这是一个公平的权衡，特别是如果所有行为都保留在聚合中。
在考虑聚合边界时，您不能完全忘记技术问题。可能Question预计 a 会有非常多的相关问题日志。在这种情况下，将整个聚合加载到内存中以进行返回小子集的查询是不切实际的。你甚至可以考虑QuestionLog自己做一个聚合。看看Vaughn Vernon的 Effective Aggregate Design 就可以深入讨论这个主题。