DDD:"文章"中的"评论"应该是一个聚合根吗?

Ant*_*oux 3 domain-driven-design aggregateroot

我开始设计第一个简单的应用程序DDD风格,我开始看到这些概念如何协同工作.

如果我设计一个经典的博客应用程序,Article类将是我的聚合根之一.我想检索文章,管理和删除所有相关数据(出版日期,作者......).我的评论有困难.起初,评论似乎是作为文章聚合的一部分的实体:关于文章创建评论,如果我删除文章,我将删除相关评论.

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

你会如何塑造它?

谢谢.

Den*_*aub 7

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

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

我将以下内容作为一般经验法则:尽可能减少聚合.当有疑问时,错误地站在更多聚合体的一边.

通过这种方式建模,您可以将注释附加到多个对象,例如ArticleUser

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
Run Code Online (Sandbox Code Playgroud)

  • @oguzh4n 一年多过去后看看我的模型,我可能会以相反的方式建模。评论通过“ArticleId”和“UserId”引用文章和评论用户。文章和用户都不需要评论 ID 列表。创建新评论将是影响一个聚合的一项事务:使用各自的 ID 创建新评论。按用户或按文章列出评论只是一种投影(可能是 SQL 数据库中的 JOIN 或事件源场景中的读取模型)。 (2认同)
  • 我正在投票,因为您已经注意到,将用户与评论ID列表耦合是一个坏主意。请在您的答案中添加一个UPDATE,这样就不会误导他人。 (2认同)