CQRS这个术语指的是一种软件架构模式和概念,从事领域驱动开发(Domain Driven Design)的软件工程专家最终都会碰到这个模式。但是,它背后的理念是什么呢?在有些场景下,CQRS为什么是比常见的N层软件架构更好的可选方案?这两种模式对比起来,各有什么特点?另外,更重要也真正的值得关注的是,“它到底能为业务带来什么?”我们试图在更为宏观的层面来剖析CQRS应用架构能够带来什么价值。
那么,基于CQRS的应用架构的关键点是什么呢?我们先从概念的定义开始吧。
命令查询职责分离(CQRS,Command Query Responsibility Segregation)是一种应用架构模式,它会将应用分为两部分:查询部分(查看模型)和命令部分(写入模型)。每一部分都负责处理特定的操作集——分别也就是读取类型和写入类型。CQRS概念最初是由Greg Young提出和积极倡导的。它是CQS(命令-查询分离)理念的自然延伸,CQS理念由Bertrand Meyers提出,主张将方法分为命令和查询。CQRS使用了相同的原则,不过将其扩大到了整个系统中。
按照这种架构,业务逻辑层的两个组件将会相互独立地运行。因此,读取模型(Read Model)将会处理用户的查询——在处理能力方面的要求会更少一些,而写入模型(Write Model)将会经历一个很长的处理路径,包括校验、队列、消息以及用户命令要执行的业务规则处理。
CQRS模式受到模型驱动开发(Domain Driven Design)拥护者的推崇。这种方式强调在实现应用的时候,将解决业务问题放在第一位。它关注的中心点在于业务领域及其发挥作用的上下文之间的紧密协作。它会聚焦于业务而不是技术问题,并且要找出特定领域中所有细微的内容,这之所以能够实现要归功于采用了一种通用语言(Ubiquitous language)——能够被实现团队、业务分析师、领域专家以及其他人员理解的语言。这门语言能够让所有的团队成员(业务和技术)共享工作成果,他们会定义通用的业务对象来描述解决方案的领域模型,还会定义这种模型中的特定上下文,在这一点上要取得共识。随后,这些业务对象会被代码本身来使用。
来源: http://www.infoq.com/cn/articles/cqrs-business-kaminski