假设我们需要实现一些需要检查对象历史（事件存储）的域规则。例如，我们有一个带有CurrentStatus属性的Order对象，我们需要检查Order.CurrentStatus更改历史记录。
你很可能会回答我需要将这些知识转移到域并引入包含状态记录集合的Order.StatusHistory属性，并且我不应该查询事件存储。我会同意你的意见。
我提出的问题是需要Event Store。
我们在具有商业意义（域值）的事件存储事件中编写，我们不记录UserMovedMouse事件（在大多数情况下）。和OrderStatusChanged事件一样，很有可能在某些时候需要来自EventStore的大多数事件用于域逻辑，并且我们最终得到一个具有EventHistory属性的域对象，其中包含事件集合。
当您拥有一个只写事件存储和多个只读查询存储时，我可以在单独的事件存储中看到CQRS等模式的值，这为您提供了一些可伸缩性。然而，在代码中引入这样的东西的需要对我来说也是个问题。所有体面的数据库都支持单写服务器，多个读服务器的可扩展性（主从复制）。我为什么要在源代码级别引入这样的东西？为什么不忘记Web服务，消息总线和使用在套接字周围编写自己的包装器。
我非常尊重“老派”DDD，因为它被描述为Eric Evans，我在新浪潮DDD + SQRC + EventSourcing模式聚合中看到了一些新鲜和好的想法。然而，CQRS的主要思想对我来说是个大问题。我错过了什么吗？
答案 0 :(得分：2)
简而言之：如果不需要事件采购（因为它的额外好处或某些怪癖的解决方法），那么你绝对不应该仅为了它而将它带入你的系统。
ES只是在有界环境中增强CQRS架构风格的众多方法之一。这不是必要条件。