假设我们需要实现一些需要检查对象历史（事件存储）的域规则。例如，我们有一个带有 CurrentStatus 属性的 Order 对象，我们需要检查 Order.CurrentStatus 更改历史记录。
您很可能会回答我需要将这些知识转移到领域并引入包含状态记录集合的 Order.StatusHistory 属性，并且我不应该查询事件存储。我会同意你的。
我的问题是 Event Store 的需求。
我们在事件存储中写入具有业务意义（领域价值）的事件，我们不记录 UserMovedMouse 事件（在大多数情况下）。与 OrderStatusChanged 事件一样，很可能在某些时候需要来自 EventStore 的大多数事件用于域逻辑，我们最终会得到一个域对象，该对象具有 EventHistory 属性和事件集合。
当您有单个只写事件存储和多个只读查询存储时，我可以在单独的事件存储中看到 CQRS 等模式的值，这为您提供了一些可伸缩性。然而，在代码中引入这样的东西对我来说也是个问题。所有像样的数据库都支持单写服务器、多读服务器的可扩展性（主从复制）。为什么我要在源代码级别引入这样的东西？为什么不忘记 Web 服务和消息总线，并使用编写自己的 Sockets 包装器。
我非常尊重“老派” DDD，因为它被 Eric Evans 描述，我在新浪潮 DDD+SQRC+EventSourcing 模式聚合中看到了一些新鲜和好的想法。然而，CQRS 的主要思想对我来说是个大问题。我错过了什么吗？