【问题标题】:Domain driven design (a sample blog application)领域驱动设计(示例博客应用程序)
【发布时间】:2013-04-24 09:26:18
【问题描述】:

我最近在学习 DDD,但不太了解这些概念。我对示例博客应用程序有一些疑问。

假设博客系统中有四个域对象:UserBlogPostComment。一个User 只能有一个Blog,一个Blog 有多个Post 实体,一个Post 有许多Comment 实体。

我的设计是Blog 是聚合根:

class Blog {
    private User;
    private List<Post> posts;
}

class Post {
    private List<Comment> comments;
}

class BlogRepository {
    public void saveBlog(Blog blog);
    public void findBlogById(long id);
    public void getAllBlogs();
}

这样设计聚合根和存储库是否正确?

我有一些要求来获取用户为所有Blog 实体添加的所有Comment 实体,并且允许User 修改她/他自己的Comment

我的问题是如何实现这些要求?

【问题讨论】:

  • 尽量避免考虑任何领域建模,例如设计数据库模式。 1 对 1 或 1 对多关系是典型的关系数据库思维。他们在 DDD 中没有位置。

标签: domain-driven-design


【解决方案1】:

虽然您提供的模型反映了领域,但它并不是最佳的 DDD 实现。使用 DDD,除了考虑实体之间的关系之外,还必须考虑事务一致性边界。因此,最好将BlogPostUser 设计为仅通过 ID 相互引用的单独聚合。此外,Blog 实体没有理由需要拥有帖子集合。您永远不需要加载整个博客,并且行为永远不会跨越多个帖子。相反,提供分页存储库方法来加载博客的帖子子集。但是,Comment 可以是值对象,因此 cmets 集合应与 Post 聚合一起加载。为用户获取所有 cmets 的最简单方法是创建一个存储库查询方法,该方法返回 read-model 以防止将查询与实体中的行为混为一谈。有关设计聚合的更多信息,请查看Effective Aggregate Design

【讨论】:

  • 由于我正在使用 DDD 开发博客引擎,因此我对这些问题进行了很多思考,我可以说 Comment 不是值对象。它是一个实体:Comment 本身与 Post 没有直接关系,并且 Post AR(我在这里只谈论域)没有理由了解 cmets。帖子和评论是相互关联的,但它们是完全独立的。一个人可以在没有其他人的情况下发挥作用。读取模型将它们“结合”起来,即便如此,也只有上下文的相关位。
  • 这当然是有道理的。您似乎可以从最初将评论建模为 VO 发展,然后当需要围绕 cmets 的更多功能时,可以将其“提升”为 AR。
  • @MikeSW:这是否意味着我需要一个 CommentRepository?
  • @davenkin 虽然我会对你的问题回答“是”,但这并不是因为它是“需要”,而是因为拥有它是有意义的。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2011-10-06
  • 1970-01-01
  • 1970-01-01
  • 2011-04-10
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多