我们真的需要一个带有事件溯源和 CQRS 模式的单独事件存储吗？

Question

假设我们需要实现一些需要检查对象历史（事件存储）的域规则。例如，我们有一个带有 CurrentStatus 属性的 Order 对象，我们需要检查 Order.CurrentStatus 更改历史记录。

您很可能会回答我需要将这些知识转移到领域并引入包含状态记录集合的 Order.StatusHistory 属性，并且我不应该查询事件存储。我会同意你的。

我质疑的是 Event Store 的需求。

我们在事件存储中写入具有业务意义（域值）的事件，我们不记录 UserMovedMouse 事件（在大多数情况下）。与 OrderStatusChanged 事件一样，很可能在某些时候需要来自 EventStore 的大多数事件用于域逻辑，并且我们最终会得到一个具有 EventHistory 属性和事件集合的域对象。

当您拥有单个只写事件存储和多个只读查询存储时，我可以在单独的事件存储中看到 CQRS 等模式的值，这为您提供了一些可扩展性。然而，在代码中引入这样的东西对我来说也是个问题。所有体面的数据库都支持单写服务器、多读服务器的可扩展性（主从复制）。为什么我要在源代码级别引入这样的东西？为什么不忘记 Web 服务和消息总线，并使用编写自己的 Sockets 包装器。

我非常尊重 Eric Evans 所描述的“老派” DDD，我在新浪潮 DDD+SQRC+EventSourcing 模式聚合中看到了一些新鲜和好的想法。然而，CQRS 的主要思想对我来说是个大问题。我错过了什么吗？

Answer 1

简而言之：如果不需要事件溯源（为了它的额外好处或作为某些怪癖的变通方法），那么您绝对不应该仅仅为了它而将它带入您的系统。

ES 只是在有界上下文中增强 CQRS 架构风格的众多方法之一。这不是必需的。