业务建模: 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,必须重构模型,这个重构的原因居然不是来自“业务领域”的变化)