手把手教你落地 DDD
钟敬
Thoughtworks 首席咨询师、数字化转型与运营团队 DDD 负责人
19697 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 45 讲
AIGC特别策划 (2讲)
结束语&结课测试 (2讲)
手把手教你落地 DDD
15
15
1.0x
00:00/00:00
登录|注册

32|CQRS(下):CQRS还有哪些变化?

你好,我是钟敬。
上节课,我们从业务需求出发,一步步推演,学习了 CQRS 的基本原理。另外,我们还学习了“代码结构分离”和“数据库结构分离”两种策略。
在这两种策略中,程序仍然在同一个微服务,数据库也只有一个实例。但是,当我们遇到更高的并发性能需求时,就要考虑分布式程序和数据库了。这就是今天的两种策略要解决的问题。之后,我们还会讨论如何权衡这些策略,做出恰当的技术决策。

应用服务分离

我们先回顾一下上节课里,“数据库结构分离”部分的架构图。
如果我们发现,使用命令的并发请求相对比较少,而使用查询的并发请求却很多,需要横向扩展才能满足性能和可用性要求,那么就可以考虑拆成两个微服务了。我们把这种策略称为“应用服务分离”。
拆分后的架构图是后面这样。
对照这张图我们可以看到,命令处理器和查询处理器原来是在同一个微服务中的,现在拆成了两个。这样,两个服务的可伸缩性就可以不一样了。例如负责处理命令的微服务可以部署在 5 个容器里,而负责处理查询的微服务部署在 10 个容器里。
另外还有一个小细节,你可以结合后面这张图看一下。
在之前的组件图里,供给接口和需求接口是直接相连的。而这里使用了表示依赖的线。这两种方法都可以。如果供给和需求接口离得比较远,或者像这张图一样,两个需求接口共用一个供给接口,就可以采用依赖的形式来描述。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

CQRS(下):CQRS还有哪些变化?本文深入探讨了CQRS的变化,主要包括应用服务分离和数据库实例分离两种策略。应用服务分离通过拆分微服务来满足高并发性能需求,而数据库实例分离则通过拆分数据库实例来解决性能瓶颈。文章还总结了各种策略的组合,强调了为了实现命令进行的查询的微妙问题。此外,还提出了两道思考题,引发读者思考。整体而言,本文深入浅出地介绍了CQRS的变化及其实际应用,对于想要深入了解CQRS的读者具有一定的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《手把手教你落地 DDD》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(12)

  • 最新
  • 精选
  • aoe
    “为了实现命令而进行的查询”其实不算 CQRS 里的 Q,而是应该在命令处理器中处理,这点提醒的太及时了,不然不知道什么时候才能从迷惑中走出来

    作者回复: 你能注意到这一点非常好! 有些同学读这一段,可能就略过去了。

    2023-03-03归属地:浙江
    3
    6
  • Fredo
    1. 如果查询比较简单,是不是可以直接走领域模型,而不用 Q 2. 搜索场景,canal 增量同步 ES;flink CDC 同步到数仓

    作者回复: 是的,CQRS不是必须要用的

    2023-03-02归属地:广东
    2
    3
  • 你来吧
    手把手教你落地DDD的源代码在哪里呢

    编辑回复: https://github.com/zhongjinggz/geekdemo 目前放出了迭代1的,后面的正在逐渐补充

    2023-03-22归属地:浙江
    3
    1
  • 黑夜看星星
    老师,请教数据库结构分离和数据库实例分离的区别

    作者回复: 一般用 create database 语句可以创建一个 database 也就是数据库实例。数据库结构分离,指的是有两套表,但还在同一个 database; 数据库实例分离,指的是在两个不同的 database.

    2023-08-28归属地:广东
    2
  • NoSuchMethodError
    比如领域服务中需要查询list,list中的item是聚合根,且只需要item中的部分属性,那么还需要挨个重新生成聚合根嘛

    作者回复: 如果仅仅是查询功能,那么不用

    2023-04-24归属地:江苏
  • 胡昌龙
    钟老师,如果一个聚合如营销补贴计算。需要用到同一限界上下文里的另一个聚合 如营销补贴规则。考虑到性能,此时希望从数据库只查询出补贴规则的局部属性,是建一个新的值对象类来接收并参与运算,还是使用原来的补贴规则聚合对象类,只是对局部属性赋值呢(感觉模型重建就不完整啦)?假设新建值对象类,那如果有多种计算场景,需要用到不同的补贴规则局部属性,这样会导致建出很多的类来,这些个类放在哪里又比较合适?

    作者回复: 需要了解更多背景,才能准确回答。营销补贴规则这个聚合有哪几个领域对象组成、作为一个聚合的理由是什么?这些对象各有多少属性?计算时希望用到属性有多少?来自于哪个对象?等等。 现在只能按常理回答一下,如果要用到的对象总共字段不多,比如5个,用到其中3个,那么整体拿出来也不会影响太大性能。如果对象字段很多,比如几十个,那么就应该进一步拆成值对象或实体。拆分的时候,不完全是按照使用的需求,而是按照业务概念。由于是按照业务概念,所以即使有不同的计算场景,拆出的实体或值对象也应该基本上保持稳定。

    2023-04-15归属地:浙江
  • 胡昌龙
    钟老师,如果一个聚合如营销补贴计算。需要用到同一限界上下文里的另一个聚合 如营销补贴规则。考虑到性能,此时希望从数据库只查询出补贴规则的局部属性,是建一个新的值对象类来接收并参与运算,还是使用原来的补贴规则聚合对象类,只是对局部属性赋值呢(感觉模型重建就不完整啦)?假设新建值对象类,那如果有多种计算场景,需要用到不同的补贴规则局部属性,这样会导致建出很多的类来,这些个类放在哪里又比较合适?

    作者回复: 已经在另一个问题里统一回复了

    2023-04-14归属地:上海
  • 胡昌龙
    钟老师,如果一个聚合如营销补贴计算。需要用到同一限界上下文里的另一个聚合 如营销补贴规则。考虑到性能,此时希望从数据库只查询出补贴规则的局部属性,是建一个新的值对象类来接收并参与运算,还是使用原来的补贴规则聚合对象类,只是对局部属性赋值呢(感觉模型重建就不完整啦)?假设新建值对象类,那如果有多种计算场景,需要用到不同的补贴规则局部属性,这样会导致建出很多的类来,这些个类放在哪里又比较合适?

    作者回复: 在另一个题里统一回复了

    2023-04-14归属地:上海
  • 老师,如果是应用和数据库都不分离的情况,用cqrs是不是可以理解为我直接跟以前一样,使用表关联查询就行?

    作者回复: 在“Q”的部分是这样的

    2023-04-12归属地:广东
    2
  • 6点无痛早起学习的和尚
    思考题: 1. 需求一:没有说清楚累计工时信息是不是 累计工时时间? 直接 select effort_item_id,xxx effort_record where emp_id = xxx and 时间区间 group by effort_item_id 需求二:把项目表、工时项、工时记录表 join 越到后面,留言越少

    作者回复: 是累计工时实践。sql 语句里少了 sum(),应该group by emp_id

    2023-02-28归属地:北京
    2
收起评论
显示
设置
留言
12
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部