嘿，我有一个聚合根，其中包含一些需要计算的属性 - totals。 这些属性不会被保存，但需要在 seed 时填充 readDto 以及在创建 aggregateRoot 时为 EventStore 填充 Event 或更新。
在 read 和 write 部分之间有一个 COMMON 服务是否是一种好习惯，它将计算这些 totals 并提供它们到 dto 或事件或任何需要它们的地方？
【问题讨论】：
标签： events domain-driven-design cqrs event-sourcing
有一个普通的服务
允许使用您通常用来实现 DRY 原则的任何有效技术（但请记住使用Rule of three 来缓和这一点）。
有时，这意味着在写入/决策过程和投影服务之间复制帮助文件。有时你甚至可以将它们编译成一个单独的帮助库。有时是动态语言中的一段代码，可以针对在决策过程、投影服务或读取器过程的上下文中水合的事件（或被折叠的一系列事件）的实例运行。
没有基本法则规定必须只有一个事物（作为单一服务运行的编译代码）拥有该规则 - 对于初学者，如果您想在不停机的情况下部署该服务的更新会发生什么？
简而言之 - 没有硬性规定；任何这样一刀切的处方药都会有数百个例外。有点像企业级通用数据模型；）
我并不害怕使用单一服务来破坏 DRY 原则。
我真正担心的是，如果使用普通的读/写东西是对的 CQRS 模式。
这通常是合法的 - 读取器和写入器都观察事件流以推断（“折叠”）滚动状态。读者可能会暴露上下文信息，这些信息可用于驱动“用户”制定表示所需动作/状态转换的命令，这些命令必然具有一定程度的重叠。关键是决策本身应该只存在于写入端（但这非常符合命令通常不应该导致反馈的一般原则 - 通常它应该是通过任何验证等幂等处理的。作为既成事实的安全- 驱动的双重检查）
其次，如果在读取部分使用逻辑违反 CQRS 模式。
一个典型的同意禁止是在保持滚动状态的折叠中具有条件逻辑 - 这应该是简单的机械累积。
对于基于观察事件维护最终一致的只读视图的投影和/或非规范化器，通常会使用重叠的简单投影逻辑。如果该逻辑变得复杂，涉及事务等，那是一种设计气味-如果事件代表自然发生的事情而不是人为的，那么它们应该倾向于相对简单地映射/投影-您实际上应该只“索引”它们或以适合读者特定需要的形式排列它们。
如果您在投影系统中遇到复杂的流程，这表明您可能有多个不同的阅读器，并且可能应该为此考虑单独的投影（即有点像接口隔离原则）
【讨论】：