业务建模: CQRS是鸡肋？

从2004年DDD诞生以来一直做领域驱动方面的实践，业务建模的过程可以说是一个痛并快乐着的过程，对于CQRS，很早就想写点什么东西，CQRS引入了对象状态、事件溯源（Event Sourcing）、快照（Snapshots）和事件存储（Event Store）等概念，Query Model与Command Model分来设计，相对于经典的DDD的设计实践无意是重大的变革。解决经典DDD复杂数据查询的问题，领域事件飞来飞去，很好很强大，建模的触角直接延伸解决分布式应用、系统性能等方面问题，从纯粹描述领域模型的角度考虑，是否有意或被迫把DDD解决的“问题域”给扩大化了，是否应该把一些架构的东西也吸收近来。简单的说，CQRS对于我们描述领域问题提供了多大助益？？？

经典的DDD的确实在复杂报表查询上存在很大不足，CQRS很好解决了这个问题，也许这个CQRS提出的初衷：》，但经典DDD实践上是采用其他的替代方案来实现，如使用原生SQL查询，将查询结果以值对象形式返回。CQRS的领域事件的订阅发布，也可以用经典DDD的Service来描述。DDD技术角度讨论实现文章已经很多，领域建模描述领域问（业务领域）的文章去不多。当然了，本人水平有限，CQRS也没具体实践过，理解有可能有偏差，愿“好事”者就这方面进行交流：）
事件保证Command与Query的数据的一致性，是CQRS的基础，事件无疑是个领域对象，但是否应该重领域对象分离出来做一个单独的领域概念，其初衷是否为适应架构设计的需要还是为了描述领域问题的需要？

当初DDD设计初衷的为了“描述业务领域问题，柔性设计”，具有“技术的不相关性”，在这个意义上，CQRS似乎有几分“反DDD经典模式”的味道。

（经典DDD的模型要“升级”到CQRS，必须重构模型，这个重构的原因居然不是来自“业务领域”的变化）