CQRS模式精讲-优快云博客

本文链接：https://blog.youkuaiyun.com/heroqiang/article/details/104345607

CQRS模式，即命令查询责任分离，将数据的读写操作分离，优化读写模型，解决复杂数据显示问题。本文深入解析CQRS的工作原理，探讨其在电商商品系统中的应用案例，以及如何提升代码质量和系统性能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

CQRS简介

命令查询的责任分离Command Query Responsibility Segregation (简称CQRS) 模式是一种架构体系模式，能够使改变模型状态和查询模型状态的动作实现分离，简单理解就是读写分离。属于DDD应用领域的一个模式。提到读写分离，我们都会用到数据库的读写分离，如MySQL数据库的主备，写主，读备，主备数据的同步由MySQL数据库底层帮我们完成。CQRS在理念上与数据库读写分离有相似之处，但二者的目的完全不同，数据库读写分离的目的是容灾、分摊压力、提升性能，CQRS旨在分离读写模型，解决数据显示的复杂性问题。在DDD的应用场景中，从资源库(Repository)中查询所有需要显示的数据是困难的，特别是在需要显示来自不同聚合类型与实例的数据时，领域越复杂，这种查询困难程度越大。

命令与查询分离

Bertrand Meyer在1988年出版的《面向对象软件架构》一书中提出了“命令查询分离”的概念，Meyer说，原则上一个方法不应该既修改数据又返回数据，所以我们就有了两类方法：

查询：返回数据，但不修改数据，所以不会产生副作用；
命令：修改数据，但不返回数据。这与SOLID中的单一职责（Single Resposibility Principle）一脉相承。

不过，仍然会有一些模式逃逸于这个原则之外。比如，正如Martin Flowler所说的，从一个队列或栈弹出一个元素时，不仅改变了这个队列或栈，还返回了一个元素。

CQRS处理流程

在这里插入图片描述
将数据CRUD的CUD（新增、修改、删除）操作和R（查询）进行分离，前者称为Command，走Command bus进入Domain对模型进行操作，而查询则从另外一条路径直接查询底层数据存储，比如报表输出、数据检索等，发挥SQL、搜索引擎、缓存等底层数据存储的优点。

具体要怎么做呢？针对同一个模型，我们将那些纯粹的查询功能从命令功能中分离出来。聚和将不再有查询方法，而只有命令方法。资源库也将变成只有add()或save()方法（分别支持创建和更新操作），同时只有一个查询方法，比如fromId()。这个唯一的查询方法将聚和的身份标识作为参数，然后返回该聚合实例。资源库不能使用其他方法来查询聚和，比如对属性进行过滤等。在将所有查询方法移除后，我们将此时的模型称为命令模型（Command Model）。但是我们仍然需要向用户显示数据，为此我们将创建第二个模型，该模型专门用于优化查询，我们称之为查询模型（Query Model）。

sample

在电商系统中，商品是一个很重要的元素，商品也是一个非常复杂的体系，商品体系涉及到多级类目、卖家信息、前后台类目、各种属性、SPU、SKU等等，领域和展现形式都非常复杂。大部分的商品系统都会支持搜索功能，所以商品系统经常需要引入搜索引擎来支持搜索功能，这样由于存储结构的不同再加上领域和展现形式的复杂性，导致商品展示的实现复杂度会非常高。页面的商品展示可能需要展示不同聚和类型的信息，这时我们不但要将数据对象转换成所需的领域实体，还需要根据页面需要的信息对领域实体信息进行整合和过滤，涉及到的领域实体越多，这个过程就会愈加的复杂。这时我们可以引入CQRS来解决这个问题：
在这里插入图片描述
首先我们将应用层服务拆分为命令服务和查询服务，将创建商品、删除商品等CUD操作走应用层命令服务进入领域层，完成对应的领域模型行为后，通过资源库将数据进行持久化然后发出领域事件，资源库的实现可以放在基础设施层，根据我们系统中选择的基础设施将数据写入存储系统，示例中我们选择的是关系型数据库。接下来我们对领域事件进行处理，将数据同步至搜索引擎，这里的实现方式有很多，例如MySQL我们可以监听它的binlog等等，实现方式我们不展开细谈，无论什么样的方式，都是对领域事件处理的一种变相实现。

对于商品的搜索功能，我们构建查询模型，查询模型可以根据数据的使用方式进行构建，也可以面向页面，总之无需受限于领域模型的结构，可以根据查询需求进行灵活的构建。搜索请求经过查询服务直接进入数据访问层，同样我们可以在基础设施层实现查询服务，解耦基础设施，搜索召回的数据对象直接转换成查询模型，无需经过领域层，这样不但能够简化查询逻辑，还能提升一定的性能。