嘿，我的汇总根具有一些需要计算的属性-总计。 这些属性不会保存，但是在创建时，需要为种子填充 readDto 和为EventStore填充 Event 或 updated 。
在 read 和 write 部分之间有一个COMMON服务是一种好习惯，它将计算这些总计并提供它们到dto或事件或任何需要它们的地方？
答案 0 :(得分：1)
拥有公共服务
允许使用通常用于实现DRY原理的任何有效技术（但请记住，请使用Rule of three进行调整）。
有时，这意味着在写/决策过程和投影服务之间复制帮助程序文件。有时，您甚至可以将它们编译到单个帮助程序库中。有时是一种动态语言的代码，可以针对在决策过程，投影服务或阅读器过程中混合的事件实例（或一系列事件被折叠）运行。
没有基本的法律说必须有一个规则（作为单个服务运行的编译代码段）拥有规则-对于初学者来说，如果您想在不停机的情况下将更新部署到该服务上会发生什么？
简而言之-没有硬性规定。任何一个适合所有说明性配方的尺寸都会有数百个例外。有点像企业范围内的通用数据模型;）我不害怕通过使用一项服务来打破DRY原则。
我真正担心的是使用普通的读/写工具是否违反 CQRS模式。
通常这是合法的-读者和作家都观察事件流以推断（“折叠”）滚动状态。读者可能会暴露上下文信息，该上下文信息可用于驱动“用户”制定表示所需动作/状态转换的命令，这些命令必定具有一定程度的重叠。关键是决策本身应该只在写方面进行（这完全符合命令通常不应导致反馈的一般原则-通常，在进行任何验证等情况下，它应该是幂等可处理的），这是既成事实的安全性驱动的双重检查）
其次，如果在读取部分使用逻辑违反了CQRS模式。
人们普遍认为不对的是在折叠中保持滚动状态的条件逻辑-这应该是简单的机械积累。
对于基于观察事件维持最终一致的只读视图的投影和/或非规格化器，通常将使用重叠的简单投影逻辑。如果这种逻辑变得复杂，涉及事务等，那只是一种设计上的味道-如果事件表示自然发生的事情并且不是人为的，则它们应该相对容易映射/投影-您实际上应该只为它们建立“索引”或以适合读者特定需求的形式布置它们。
如果您最终在投影系统中遇到了复杂的流程，则表明您可能有多个不同的读者，并且应该为此考虑单独的投影（例如，有点像接口隔离原理）