CQRS架构
命令查询的责任分离Command Query Responsibility Segregation (简称CQRS)模式是一种架构体系模式,能够使改变模型的状态的命令和模型状态的查询实现分离。这属于DDD应用领域的一个模式,主要解决DDD在数据库报表输出上处理方式。
Greg Young在infoQ的采访中“State Transitions in Domain-Driven Design”谈到了CQRS,Greg 解释了把领域模型分为两种:状态校验,以及状态转换,维持当前状态的一个视图。
在客户端就将数据的CRUD的新增修改删除CUD等操作和查询R进行分离,前者称为Command,走Command bus进入Domain对模型进行操作,而查询则从另外一条路径直接使用SQL对数据进行操作,比如报表输出等,发挥SQL的特点。
当一个Command进来时,从仓储Repository加载一个聚合aggregate对象群,然后执行其方法和行为。这样,会激发聚合对象群产生一个事件,这个事件可以分发给仓储Repository,或者分发给Event Bus事件总线,比如JavaEE的消息总线等等。事件总线将再次激活所有监听本事件的处理者。当然一些处理者会执行其他聚合对象群的操作,包括数据库的更新。
下图是开源JiveJdon的CQRS图:
在JiveJdon中,查询数据库是使用缓存,而写入数据库使用普通MySQL,两者之间数据同步通过领域事件实现最终一致性。
查询与写入数据库的分离,可以实现专门为各自查询 读取而设计特别的数据表结构,专门为查询进行优化。
如果采取事件溯源EventSourcing,保存记录的不是聚合当前状态,而是导致状态变化的事件日志 ,那么可以回放,从而找到重要状态改变的轨迹与原因,这是从事件日志追溯来源。
虽然这种架构有些复杂,但是好处却很多,主要的是实现透明的分布式处理Transparent distributed processing,当使用事件作为状态改变的引擎时,你可以通过实现多任务并发处理,比如通过JVM并行计算或事件消息总线机制,事件能够很容易序列化,并在多个服务器之间传送。而查询操作则专门优化。
教程与文章
《复杂软件设计之道:领域驱动设计全面解析与实战》有专门章节讲解CQRS
业务建模:CQRS应用场景
如何更好地在实践中实现DDD,又防止技术架构对业务领域的侵害,本文讨论引入CQRS使用场景。事件是一等公民
Java的CQRS和事件溯源ES入门:如何从CRUD切换到CQRS/ES
领域事件和EventSourcing
你的SOA已经使用了EDA和CQRS吗?
DDD CQRS和Event Sourcing的案例:足球比赛
使用CQRS重新考虑架构
使用TRIMM 为EA项目产生基于Axon的CQRS代码
Martin Fowler推荐的事件源Event Sourcing 架构:LMAX架构
DDD CQRS架构和传统架构的优缺点比较
Lagom是一个集成ES/CQRS的Reactive微服务框架
如何理解Stream processing, Event sourcing, Reactive, CEP?
CQRS解构
Saga与工作流引擎比较
最全面的CQRS和事件溯源介绍
经验分享:采用事件溯源的误区(以及我们是如何避免的)
在分布式事务失败的情况下实现一致性:在线事件处理OLEP(事件溯源) - ACM权威
否定洋葱或clean架构的垂直切片架构 - Jimmy Bogard
CQRS框架Axon框架指南 - Baeldung
Jdon分析法
Jdon框架CQRS入门
Apache Kafka和Spring Boot的容错和可靠消息传递
Redis如何简化微服务设计模式
在使用Kafka+微服务发送聚合的领域事件时如何在错误重试时保证顺序?
更多#CQRS
#领域事件 #EventStorming #Event Sourcing