4

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

我读了很多关于限界上下文的文章，在我看来，这是所有这一切中最微妙的方法，也许是最难解释和在实际项目中应用的东西。

幸运的是，我的域名非常简单；-)

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

域规则非常简单：

  • 当作者 撰写博客文章时，他必须选择一个类别来保存他的文章，并且他可以选择多个标签来提高他的文章可见性

  • 当读者访问博客时，他可以按类别或标签浏览博客文章

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

  • 用户（作者）撰写帖子上下文。在这些上下文中，P​​ost是聚合根

  • 用户（读者）按类别浏览帖子。在这些上下文中，类别是聚合根。

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

我想对了吗？

鉴于我是（正确的），我想知道，在执行此操作时，谁负责创建不同的对象和关系？

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

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

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

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

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

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

谢谢。

4

1 回答 1

5

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

不，博客应用程序通常只会跨越一个有界上下文。当模型在不同的上下文中具有不同的含义时，您需要多个 BC。这通常发生在您要处理的域变得有点大时，由多个子域组成。

但是，您将拥有多个聚合 - 您可以在单个 BC 中拥有多个聚合根。确定域模型中的聚合基于几个因素。首先，聚合形成了围绕与某个根实体相关联的一组内聚行为的一致性边界。例如，一个Post很可能是一个 AR，就像Writer (Author)一样。如需深入了解聚合设计，请查看有效聚合设计。

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

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

于 2013-05-29T14:42:19.940 回答