Dojo
最新
最佳
搜索
订阅
解道Jdon
架构设计
领域驱动
DDD介绍
DDD专辑
战略建模
领域语言UL
领域事件
商业分析
工作流BPM
规则引擎
架构师观点
数据工程
产品经理
系统思维
微服务
微服务介绍
微服务专辑
模块化设计
SOA
API设计
clean架构
SpringBoot
分布式事务
分布式架构
Kubernetes
DevOps
编程设计
GoF设计模式
模式专辑
面向对象
函数式编程
编程语言比较
编程工具比较
形式逻辑
前端编程
Reactive编程
Jdon框架
Rust语言
人工智能
Web3
模因梗
幽默梗
程序员吐槽
面试技巧
Java入门
数字化转型
认知偏差
道德经
更多话题
观点:实现CQRS分离不如实现一致性分离 - @jroper
19-01-16
banq
我开始认为
CQRS
分离方向是错误的,我们不应该在命令和查询之间分离责任,而是在业务需要强烈一致的操作和可能弱一致的操作之间。
这意味着如果业务需要读取您自己的写入,那么您不必向后弯曲以实现它,您只需在强一致性方面执行该读取操作。
它还允许更灵活的写入,因为您可以在业务允许的弱一致性方面进行编写。这种方法的一个实现可能是使用CRDT,强一致性方面是单个可寻址的持久复制品。
在一天结束时,企业真的关心某件事是命令还是查询?事实并非如此,企业关心的是一致性和顺序(banq注:数据的准确性 数据的完整性),或者更具体地说,它关心的是什么时候保证,什么时候不保证。
通过命令和查询进行隔离并不能完全映射到业务所关注的内容,而是通过强弱一致性级别进行隔离。
因此,或许我们应该做出强烈一致的弱一致责任隔离:SWRS。在大多数情况下,它看起来与CQRS非常相似,只是功能更强大,更适合业务需求。
当然,实际实现这是有挑战的: 命令和查询是客观分类的,一致性要求可能是非常主观的(尽管技术上可行,例如跨实体连接,确实使分类有时是客观的)。
banq注:CQRS其实是技术
架构
上分离,也就是读写分离,而一致性是业务关注点,实际上
DDD
聚合是高一致性的设计结果,因此CQRS一般必须加上DDD,这样DDD帮助你实现一致性分离,哪些得到保证?聚合里的数据更新会得到高一致性保证,哪些不能得到保证,跨聚合操作等,这些是弱一致性,甚至可以通过流程来保证。
1
CQRS命令查询分离架构
DDD聚合
分布式共识一致性专栏