对博客文章的评论应该是聚合根吗？答案

【问题标题】：Should a comment on a blog post be an aggregate root?对博客文章的评论应该是聚合根吗？
【发布时间】：2020-06-03 11:34:59
【问题描述】：

我读过一个聚合应该被它的聚合根封装。如果聚合根不存在，则聚合不应该存在，我们应该只通过它的根访问聚合。

举个例子：我有一个视频网站，视频很少，而这些视频可能有很多 cmets。

在我看来，视频是聚合根，评论是聚合，因为没有视频，评论就没有意义。

但是我如何在不从数据库中加载所有 cmets 的情况下检索它们？那将是一个很大的性能打击。延迟加载可能是一种解决方案，但我读过不建议这样做。

评论可以是它自己的聚合根，所以我可以独立查询它，但这会破坏“没有根的存在”规则，对吧？

【问题讨论】：

考虑一下你为什么关心是否每条评论都有一篇博文可能会有所帮助。
您对聚合和聚合根的定义是错误的。聚合是对象的集群，聚合根是该集群的根。请参阅：stackoverflow.com/a/1958765/1066906 和 stackoverflow.com/questions/20601937/…
查看@VoiceOfUnreason 的评论。从您的示例中：无法确定评论是否可以是它自己的汇总。还要记住，没有完美的模型。应用 DDD 时应根据业务规则建模。不要陷入对象思维的陷阱。这有点换位思考了。确保您没有试图使用 DDD 使事情变得过于复杂。对于 CRUD，这将是不必要的。

标签： aggregate domain-driven-design ddd-repositories

【解决方案1】：

您通过从持久性角度考虑聚合来捕捉自己。在聚合中，某物是否是某物的一部分或某物是否具有某物并不重要。这些是关系术语。重要的是共享同一根的对象的概念统一性。这种统一的一个副作用是事务边界 - 然后在存储库和存储机制的帮助下用于保存聚合。聚合不关心它是否会被保存。存储库接口（作为域的一部分）的存在只是因为我们受到包含数据库的架构的限制。注意行为、业务规则、凝聚力。聚合是一个非常复杂的过程，然后在 DDD 书籍中进行了介绍。

看看人生游戏。这些小方块都聚集在一些共同的根周围。他们不在乎他们是否会得救。他们只是在完成他们的使命。它们不是聚合的一部分，它们是更动态和复杂的东西的一部分。在 DB 中保存 Game of life 的快照并不能告诉您太多关于它们的性质。

另外，不要认为查询是固定的。可以通过多种不同方式（部分或整体）加载和获取聚合。这是应用程序的工作。首先考虑查询意味着您将聚合视为数据的集合。

【讨论】：

【解决方案2】：

我认为你处理了 2 个不同层次的问题。

概念 => 我将如何定义聚合等。

实施 => 我的系统会很慢

如果您认为加载 cmets 会遇到问题，您可以优化您的实现。

【讨论】：