业务建模: CQRS是鸡肋?

12-08-26 clonalman

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

7
clonalman
2012-08-26 10:59
是否有必要讨论一下"架构"与"领域"之间的关系?

“领域”建模是否需要迁就于系统架构?

“架构”的变化如何还保证“领域”模型的稳定?

[该贴被clonalman于2012-08-26 13:27修改过]

banq
2012-08-27 09:20
写得很有深度,CQRS确实为了让DDD落地,而技术架构和业务领域的实现总是有一段距离,如何弥补这个鸿沟诞生了事件驱动架构EDA或CQRS、还有DCI以及BDD等等。

至于业务领域与技术架构的关系,我个人认为根据业务领域选择合适的技术架构,根据业务领域去优化微调技术架构。

比如如果业务领域是面向普通大众用户的,那么架构性能就很重要,而CQRS也能解决这个问题,因为C命令和Q查询分离实际是写读分离,POST/GET分离,伸缩性很好,见另外一篇文章:破除CQRS的神话

clonalman
2012-08-27 12:11
1、理论上,用任何架构或不使用架构都能使DDD落地

2、业务模型不应该有面向大众或小众区别,一个系统100个人可以使用,100万使用崩溃,能说100人使用的领域模型是正确,100万人使用领域模型就变为错误了吗?

领域建模的边界必须是有限,系统性能架构来解决,领域与架构的解决“问题域”边界是否是交叉的?(除非领域建模的“问题域”就是架构本身)

clonalman
2012-08-27 12:25
愿意还是不愿意,个人觉得CQRS都不能放在领域模型当中,它能发挥的作用的理想场所应该在基础设施层,而且在“领域层”与“基础设施层”还需要一层的“胶水”,来粘合“领域层”与“基础设施层”的距离,同时消除“基础设施层”由于不同架构选型对“领域层”的冲击。

不是知道Banq是否有这方面的思考?这个“胶水”应该是一个什么东西?

[该贴被clonalman于2012-08-27 12:35修改过]

猜你喜欢
3Go 1 2 3 下一页