项目架构实战：分层架构规范之CQRS分离

一、引入的目的

领域驱动作为一种系统分析的方法论，分清了职责范围、通过分层剥离了业务逻辑，但是在实践过程中依然会遇到很多问题。例如常见的查询问题： 一个业务系统会存在各种查询功能，例如列表查询、分页查询等，没有业务逻辑(或者很少)，如果按照常规的领域分层会导致大量的模型转换工作，并且存在大量的分页信息(pageSize\pageNo\totalPage等)无处安放，因为它们并不属于Domain内的属性或行为，如果算Domain里的属性，会导致Domain越来越大。

CQRS正好可以解决领域驱动中的查询问题

二、什么是CQRS

CQRS(Command Query Responsibility Segregation)，Command 与 Query 分离的一种模式。

Command：命令则是对会引起数据发生变化操作的总称，即新增，更新，删除这些操作，都是命令

Query：查询则不会对数据产生变化的操作，只是按照某些条件查找数据

CQRS 的核心思想是将这两类不同的操作进行分离，可以是两个独立的应用，两个不同的数据源，也可以是同一个应用内的不同接口上。

从上图可看出，把数据的变更通过数据同步到另一个库用来查询数据，其实就是数据异构。但这不是我们现在需要做的，我们是要利用CQRS的思想解决领域驱动中查询功能实现复杂的问题

三、领域驱动中落地CQRS

落地的DDD+CQRS使用了对称性架构，如下图：

 

 

1.当一个命令Command请求过来时，会通过应用层的CommandService去协调领域层工作
2.当一个查询Query请求过来时，则直接通过基础实施的实现与数据库或者外部服务交互

以上是理论上的描述，在应对大量查询功能的实际场景如何落地呢？
1.在Facade.api层对每个模块分离出CommonController\QueryController
2.在QueryController直接使用Mapper直接查询DB，并完成Entity-->Response的转换