读写通用服务-CQRS+DDD

共同服务

允许使用任何有效的技术来实现干燥原理(但要记住要用 Rule of three ).

有时,这意味着在写/决策过程和投影服务之间复制帮助程序文件。有时候你甚至可以把它们编译成一个助手库。有时是动态语言中的一段代码,可以在决策过程、投影服务或读取器过程的上下文中针对事件实例(或折叠的一系列事件)运行。

没有一条基本定律规定必须有一件事(作为单个服务运行的已编译代码)拥有规则-首先,如果您想在不停机的情况下将更新部署到该服务,会发生什么情况?

简而言之,没有硬性规定;任何这种一刀切的处方都有数百个例外。有点像企业范围的通用数据模型;)

我不怕用单一的服务来打破干巴巴的原则。

我真正关心的是,使用普通的读/写功能是否会违反 CQRS模式。

通常这是合法的-读者和作者都观察事件流以推断(折叠)滚动状态。读者可能会暴露上下文信息,这些信息可用于驱动“用户”制定表示所需操作/状态转换的命令,这些操作/状态转换必然有一定程度的重叠。关键是决策本身应该只存在于写端(但这很好地符合一般原则,即命令通常不应该导致反馈-通常它应该是可以在任何验证等情况下进行等幂处理的,这是一种既成事实的安全驱动的双重检查)

其次,如果在读取部分使用逻辑违背CQRS模式。

一个典型的同意no是在保持滚动状态的褶皱中有条件逻辑-这应该是简单的机械累积。

对于基于观察事件而保持最终一致只读视图的投影和/或非规范化器,通常使用重叠的简单投影逻辑。如果逻辑变得复杂,涉及交易等,这是一个设计气味虽然-如果事件代表什么是自然进行,而不是人为的,他们应该倾向于相对简单的地图/项目-你应该真正是“索引”他们或铺设在一个适合读者的特定必需品的形式。

如果你在投影系统中以复杂的流结尾,这表明你可能有多个不同的阅读器,也许应该考虑到这一点的单独投影(即,有点像界面分离原理)