项目架构实战:分层架构规范之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的转换

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章