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