domain-driven-design - CQRS/DDD : The dummy blog/post/category/tags example

Question

仍在深入研究 CQRS 实现实验，我决定从头开始我的博客并将其用作沙箱。

我阅读了很多关于有界上下文的内容，在我看来，这是所有这些中最微妙的方法，也许是在实际项目中最难解释和应用的方法。

幸运的是，我的域名很简单;-)

我尝试识别不同的有界上下文，并确定哪个模型成为每个上下文中的聚合根。

域规则非常简单:

当作家 写博客 发帖 他必须选择一个 类别 救他的发帖 在，他可以选择多个标签 改善他的 发帖 知名度

当读者访问博客，他可以浏览博客帖子 来自 类别 或通过 标签

只有这些规则，我们已经得到了几个有界上下文，对吗？

用户(作者)组成一个帖子上下文。在这些情况下，发帖 是聚合根

用户(读者)按类别浏览帖子。在这些情况下，分类 是聚合根。

用户(读者)按标签浏览帖子。在这种情况下，好吧，我不确定... ;-)

我想的对吗？

鉴于我是(正确的)，我想知道，在实现这一点时，谁负责创建不同的对象和关系？

以用户撰写新博客文章的上下文为例，我真的不知道应该在哪里创建标签实例以及是否应该在写入模型中创建帖子与其标签之间的关系。类别也是如此，不知道:p

此外，有界上下文是否意味着特定模型？这意味着对于每个有界上下文，我都会有一个不同的对象图(在写入模型中)？

需要一些脑电波才能在我的脑海中清楚地看到这一点;-)

为了添加新帖子，到目前为止，我的 Controller 要求命令总线处理“ComposeCommand”，处理程序(PostService)创建一个新的“Post”实例，在其上调用 compose 方法，最后要求写入持久性保存最新帖子。

Post::compose() 方法会引发“PostComposedEvent”事件，读取模型会监听该事件以更新其数据。

在这一切中，我不知道如何引入“类别”和“标签”。

谢谢。

Answer 1

With only these rules, we already get several bounded contexts, am I right ?

不，一个博客应用程序通常只会跨越一个单一的有界上下文。当模型在不同的上下文中具有不同的含义时，您需要多个 BC。这通常发生在您正在寻址的域由多个 sub-domains 组成的较大的域时。 .

但是，您将拥有多个聚合 - 您可以在单个 BC 中拥有多个聚合根。确定域模型中的聚合基于几个因素。首先，聚合围绕与某个根实体相关联的一组内聚行为形成了一致性边界。例如，帖子很可能是 AR，作家(作者)也是如此。如需深入了解骨料设计，请查看 Effective Aggregate Design .

In all this I don't know how to introduce "Category" and "Tags".

通常，在您的情况下，将帖子类别和一组标签指定为创建帖子的命令的一部分 - ComposeCommand。根据您将 Category 和 Tag 建模为聚合还是值对象，该命令将指定 CategoryId 和 TagIds，或仅指定值。