极端想法：这个CQRS其实就是个补丁。弥补领域模型不适合大规模数据联合查询统计的问题。
DDD 作为一种系统分析的方法论，最大的问题是如何在项目中实践。而在实践过程中必然会面临许多的问题，「模式」是系统架构领域中一种常见的手段，能够帮助开发人员与架构师在遭遇某种较为棘手，或是陌生的问题时，参考已有的成熟经验与解决方案，从而优雅的解决自己项目中的问题。
从本期开始，我会开始介绍 DDD 中一些常见的模式，包括这些模式的背景，作用，优缺点，以及在使用过程中需要注意的地方。而本次的主角就是 CQRS，中文名为命令查询职责分离。
毋庸置疑「领域」在 DDD 中占据了核心的地位，DDD 通过领域对象之间的交互实现业务逻辑与流程，并通过分层的方式将业务逻辑剥离出来，单独进行维护，从而控制业务本身的复杂度。
但是作为一个业务系统，「查询」的相关功能也是不可或缺的。在实现各式各样的查询功能时，往往会发现很难用领域模型来实现。假设在用户需要一个订单相关信息的查询功能，展现的是查询结果的列表。列表中的数据来自于「订单」，「商品」，「品类」，「送货地址」等多个领域对象中的某几个字段。这样的场景如果还是通过领域对象来封装就显的很麻烦，其次与领域知识也没有太紧密的关系。
此时 CQRS 作为一种模式可以很好的解决以上的问题，那么具体什么是 CQRS 呢？又如何实现呢？
CQRS — Command Query Responsibility Segregation，故名思义是将 command 与 query 分离的一种模式。query 很好理解，就是我们之前提到的「查询」，那么 command 即命令又是什么呢？
CQRS 将系统中的操作分为两类，即「命令」(Command) 与「查询」(Query)。命令则是对会引起数据发生变化操作的总称，即我们常说的新增，更新，删除这些操作，都是命令。而查询则和字面意思一样，即不会对数据产生变化的操作，只是按照某些条件查找数据。
CQRS 的核心思想是将这两类不同的操作进行分离，然后在两个独立的「服务」中实现。这里的「服务」一般是指两个独立部署的应用。在某些特殊情况下，也可以部署在同一个应用内的不同接口上。
Command 与 Query 对应的数据源也应该是互相独立的，即更新操作在一个数据源，而查询操作在另一个数据源上。看到这里，你可能想到一个问题，既然数据源进行了分离，如何做到数据之间的同步呢？让我们接着往下看。
让我们先看一下 CQRS 的架构图:
从图上可以看到，当 command 系统完成数据更新的操作后，会通过「领域事件」的方式通知 query 系统。query 系统在接受到事件之后更新自己的数据源。所有的查询操作都通过 query 系统暴露的接口完成。
从架构图上来看，CQRS 的实现似乎并不难，许多开发者觉得无非是「增删改」一套系统一个数据库，「查询」一个系统一个数据库而已，有点类似「读写分离」，并没有什么特别的地方。但是真正要使用 CQRS 是有许多问题与细节要解决的。
其实仔细的思考一下，你应该很快会发现 CQRS 需要面临的一个最大的问题: 事务。在原本单一进程，单一数据源的系统中，依靠关系型数据库的事务特性能够很好的保证数据的完整性。但是在 CQRS 中这一切都发生了变化。