仍在深入研究CQRS实施实验，我决定从头开始浏览我的博客并将其用作沙盒。
我读了很多有关有界背景的内容，在我看来，这是所有这些中最精巧的方法，也许是解释和应用于实际项目中最困难的事情。
幸运的是，我的域名非常简单; - ）
我尝试识别不同的有界上下文，并确定哪个模型成为每个上下文中的聚合根。
域规则非常简单：
当作家 撰写博客帖子时，他必须选择类别来保存他的发布，并且他可以选择多个标记来提高帖子的可见性
当读者访问博客时，他可以按类别或标记帖子 >
只有这些规则，我们已经得到了几个有界的背景，我是对的吗？
用户（编写者）编写帖子上下文。在这些情况下，帖子是聚合根
用户（读者）按类别浏览帖子。在这些情况下，类别是聚合根。
用户（读者）按标签浏览帖子。在这种情况下，我不确定......; - ）
我认为对吗？
鉴于我（对），我想知道，在实施这个过程中，谁负责创建不同的对象和关系？
以用户撰写新博客帖子的上下文为例，我真的不知道应该在哪里创建标签实例，以及我是否应该在写入中创建Post及其标签之间的关系模型。类别也是如此，不知道：p
此外，有界上下文是否意味着特定模型？这意味着对于每个有界上下文，我会有一个不同的对象图（在写模型中）？
需要一些脑电波来清楚地看到这一点; - ）
为了添加新帖子，到目前为止，我的控制器要求命令总线处理“ComposeCommand”，处理程序（PostService）创建一个新的“Post”实例，在其上调用compose方法并最终询问写入持久性保存新帖子。
Post :: compose（）方法引发一个“PostComposedEvent”事件，读取模型侦听该事件以更新其数据。
在这一切中，我不知道如何介绍“类别”和“标签”。
感谢。
答案 0 :(得分：5)
只有这些规则，我已经得到了几个有限的背景，我 对吗？
不，博客应用程序通常只会跨越一个有限的上下文。当模型在不同的上下文中具有不同的含义时，您需要多个BC。这通常发生在您正在寻址的域变得有点大的时候，包含多个sub-domains。
但是，您将拥有多个聚合 - 您可以在一个BC中拥有多个聚合根。确定域模型中的聚合是基于几个因素。首先，聚合形成围绕与某个根实体相关联的一组内聚行为的一致性边界。例如， Post 可能是AR，因为 Writer（作者）。要深入了解聚合设计，请查看Effective Aggregate Design。
在这一切中，我不知道如何介绍“类别”和“标签”。
通常，将一个帖子类别和一组标签指定为命令的一部分，该命令会在您的案例中创建post- ComposeCommand 。根据您是否将类别和标记建模为聚合或值对象，该命令将指定 CategoryId 和 TagIds ，或仅指定值。