DDD领域驱动设计：CQRS架构模式

文章目录

前言一、 CQRS介绍1.什么是 CQRS2.为何要使用CQRS 二、CQRS 架构1.单数据库 CQRS2.双数据库 CQRS3.事件源 (Event source) CQRS 结尾

前言

DDD 作为一种系统分析的方法论，最大的问题是如何在项目中实践。而在实践过程中必然会面临许多的问题，「模式」是系统架构领域中一种常见的手段，能够帮助开发人员与架构师在遭遇某种较为棘手，或是陌生的问题时，参考已有的成熟经验与解决方案，从而优雅的解决自己项目中的问题。

本篇介绍的是CQRS，中文名为命令查询职责分离。

一、 CQRS介绍

1.什么是 CQRS

CQRS — Command Query Responsibility Segregation，故名思义是将 command 与 query 分离的一种模式。query 很好理解，就是我们之前提到的「查询」，那么 command 即命令又是什么呢？

CQRS 将系统中的操作分为两类，即「命令」(Command) 与「查询」(Query)。命令则是对会引起数据发生变化操作的总称，即我们常说的新增，更新，删除这些操作，都是命令。而查询则和字面意思一样，即不会对数据产生变化的操作，只是按照某些条件查找数据。

CQRS 的核心思想是将这两类不同的操作进行分离，然后在两个独立的「服务」中实现。这里的「服务」一般是指两个独立部署的应用。在某些特殊情况下，也可以部署在同一个应用内的不同接口上。

Command 与 Query 对应的数据源也应该是互相独立的，即更新操作在一个数据源，而查询操作在另一个数据源上

2.为何要使用CQRS

毋庸置疑「领域」在 DDD 中占据了核心的地位，DDD 通过领域对象之间的交互实现业务逻辑与流程，并通过分层的方式将业务逻辑剥离出来，单独进行维护，从而控制业务本身的复杂度。

但是作为一个业务系统，「查询」的相关功能也是不可或缺的。在实现各式各样的查询功能时，往往会发现很难用领域模型来实现。假设在用户需要一个订单相关信息的查询功能，展现的是查询结果的列表。列表中的数据来自于「订单」，「商品」，「品类」，「送货地址」等多个领域对象中的某几个字段。这样的场景如果还是通过领域对象来封装就显的很麻烦，其次与领域知识也没有太紧密的关系。

此时 CQRS 作为一种模式可以很好的解决以上的问题。