CQRS并不复杂

两天前Rob Ashton写了一篇博客CQRS is too complicated,实际内容是说CQRS并不复杂,只是要看你怎么去实施(以及别把PPT整得太复杂)。

摘要如下(顺序有打乱,我自己怎么理解起来方便怎么总结-v-)

一说起CQRS,人们头脑中就是这样的东西

实际上,CQRS在高层次的意义上来说,就是要读写分离,跟事件溯源啊神马的并不一定有联系。

首先看这样一个经常见到的所谓N层架构

很大的问题在于这个架构尝试用统一的模型去访问数据,然而实际上读操作是简单的,不同于写操作要经过很多疯狂的逻辑例如验证、更新队列、第三方系统、业务规则之类。这种模型也往往是为写操作特殊优化过。实际上大型系统中往往会让读操作不经过所谓的“统一模型”,直接用SQL或者存储过程访问数据库,变成下面这种样子。

这现在其实已经是一种CQRS了,在更高层次的意义上来说,我们已经将我们的读写模型分离,然后再method级别做了一些非常类似于我们称之为CQS的事情。这本身应该已经让人满足:CQRS本身并不复杂,值得关注。

一些例子

CQRS可以用文本型数据库来实现,例如Raven或者Couch。用document来作为写仓储,用index作为读仓储。

如果你喜欢ORM,你也可以这样构建你的读写分离,即使你只用一个数据库(有趣的是、越是使用NHibernate越是觉得需要读写分离)

当然也可以搞双数据库,数据写入写数据库后直接计算成为为View优化过的样子存入读数据库。

即使加上事件溯源也没那么复杂。其实就是把写数据作为事件抛出来,让其他东西有机会处理一下。

说实话原文没太读懂,希望英语好的各位多指教= =

另原作者特别说了一句,本文和DDD半毛钱关系都没有,所以看到存储过程神马的也请勿喷。

posted @ 2011-09-30 14:09  jiaxingseng  阅读(...)  评论(... 编辑 收藏