Domain driven design 我们真的需要一个具有事件源和CQRS模式的独立事件存储吗？

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

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

我想问的是事件存储的需求

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

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

---

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

简言之：如果不需要事件源（为了它的附加好处或作为一些怪癖的解决办法），那么你绝对不应该为了它而将它引入你的系统

ES只是在有限的上下文中增强CQRS体系结构风格的众多方法之一。这不是一项要求