DDD：“文章”中的“评论”应该是聚合根吗？答案

【问题标题】：DDD: should "Comment" in an "Article" be an aggregate root?DDD：“文章”中的“评论”应该是聚合根吗？
【发布时间】：2012-09-12 07:31:21
【问题描述】：

我开始设计第一个简单的 DDD 风格的应用程序，并且开始了解这些概念如何协同工作。

如果我设计一个经典的博客应用程序，Article 类将是我的聚合根之一。我想检索文章、管理和删除所有相关数据（出版日期、作者...）。我在使用 cmets 时遇到困难。起初，评论似乎是文章聚合的一部分：评论是针对一篇文章创建的，如果我删除一篇文章，我将删除相关的 cmets。

然后我想在博客上显示一个小框，其中包含博客上发布的最新 cmets，用于任何文章。所以看起来我想从我的数据存储中检索 cmets（并且只有 cmets）。根据我对 DDD 思想的理解，这使它成为一个聚合根。但这似乎并不完全正确，因为评论似乎强烈依赖于文章。

你会如何建模？

谢谢。

【问题讨论】：

标签： domain-driven-design aggregateroot

【解决方案1】：

当您考虑它时，您可能会发现为什么Comment 应该是一个聚合本身的各种原因：

您要列出最新的 cmets
您可能希望列出特定用户的所有 cmets
您可能希望 cmets 嵌套（评论是对另一评论的回复）
您可能希望通过管理界面批准/拒绝 cmets
用户可能想要编辑或删除他/她的评论
...

我将以下作为一般经验法则：使您的聚合尽可能小。如有疑问，请选择更多聚合。

通过这种方式建模，您可以将 cmets 附加到多个对象，例如 Article 和 User

Comment
    string Text
    string UserName
    bool IsApproved

Article
    string Title
    string Body
    ...
    List<CommentIds> CommentIds

User
    string UserName
    ...
    List<CommentIds> CommentIds

ListOfTenLatestComments
    List<CommentIds> CommentIds

【讨论】：

非常感谢您的建议，我确实回答了我的问题。
您为最近的十条评论创建了一个聚合？是不是更像是对cmets的看法？
@AntoineRoux 都可以。取决于上下文。为此，我通常使用域事件来填充视图，但在我的回答中提到这一点会偏离最初的问题。
@oguzh4n 一年多过去了再看我的模型，我可能会反过来建模。评论通过ArticleId 和UserId 引用文章和评论用户。文章和用户都不需要评论 ID 列表。创建一条新评论将是一项影响一个聚合的事务：创建具有相应 id 的新评论。按用户或按文章列出 cmets 只是一种投影（可能是 SQL 数据库中的 JOIN 或事件源场景中的读取模型）。
我是，不要投票，因为正如您已经注意到的，将用户与评论 ID 列表结合是一个坏主意。请在您的答案中添加更新，以免误导其他人。