21 | 网约车系统重构:如何用 DDD 重构网约车系统设计?
李智慧
该思维导图由 AI 生成,仅供参考
你好,我是李智慧。
软件开发是一个过程,这个过程中相关方对软件系统的认知会不断改变。当系统现状和大家的认知有严重冲突的时候,不重构系统就难以继续开发下去。此外,在持续的需求迭代过程中,代码本身会逐渐腐坏,变得僵硬、脆弱、难以维护,需求开发周期越来越长,bug 却越来越多,系统也必须要进行重构。
我们在前一篇讨论的 Udi 网约车系统经过了几年的快速发展,随着业务越来越复杂,功能模块越来越多,开发团队越来越庞大,整个系统也越来越笨拙、难以维护。以前两三天就能开发完成的新功能,现在要几个星期,开发人员多了,工作效率却下降了。
Udi 使用微服务架构,开始的时候业务比较简单,几个微服务就可以搞定。后面随着功能越来越多,微服务也越来越多,微服务之间的依赖关系也变得越来越复杂,常常要开发一个小功能,却需要在好几个微服务中进行修改。后来开发人员为了避免这种复杂性,倾向于把所有功能都写在一个微服务里,结果整个系统架构又开始退回到单体架构。
基于以上原因,我们准备对 Udi 进行一次重构,核心就是要解决微服务设计的混乱,梳理、重构出更加清晰的微服务边界和微服务之间的依赖关系。我们准备使用 DDD,即领域驱动设计的方法进行这次重构。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
网约车系统重构是一个必要的过程,特别是在系统现状和认知有严重冲突、代码腐坏、需求开发周期变长、bug增多的情况下。本文介绍了如何使用领域驱动设计(DDD)来重构网约车系统,以解决微服务设计的混乱和梳理微服务边界和依赖关系。文章详细介绍了DDD的一般方法,包括领域拆分、限界上下文、上下文映射图等,并结合实际案例展示了如何应用DDD方法对Udi微服务进行重新分析设计和系统重构。最后,文章总结了使用DDD进行系统重构的六个步骤,并提出了思考题,引发读者对DDD的价值和成功落地的思考。整体而言,本文通过实际案例和详细步骤,为读者提供了在系统重构中应用DDD的指导和思路。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《李智慧 · 高并发架构实战课》,新⼈⾸单¥59
《李智慧 · 高并发架构实战课》,新⼈⾸单¥59
立即购买
登录 后留言
全部留言(11)
- 最新
- 精选
- My似乎懂了,又似乎没懂!!愁人
作者回复: 如果现在有人拿了几十亿找你做技术合伙人,一起搞个网约车平台,你一下就懂了~~~
2022-04-132 - HappyHasson这节课平时没接触过,或者没有仔细思考过,个人感觉挺难的,现在我们系统中确实有设计混乱的问题,但是个人感觉还是无从下手
作者回复: 意识到问题的存在和并知道了解决问题的方向,就已经成功了一半
2022-04-102 - Steven这节课的话题太大,有两个问题请教老师: 1,子域和限界上下文的图,用什么工具可以画? 2,订单上下文部分,订单聚合不应该有的功能(比如抢单)要放在什么上下文里面?
作者回复: 1 UML 组件图 2 派单
2022-04-06 - peter请教老师两个问题啊: Q1:DDD比较难吧,小的创业公司,限于技术水平,是不是不宜采用DDD来设计系统? Q2:能否讲一下红包系统设计?
作者回复: 1 小创业公司意味着业务比较简单,将来的业务变化可能性大,用DDD确实收益不大。但是说DDD比较难也不恰当,DDD的进入门槛比较高,其实熟练了也并不难。
2022-04-062 - wkq2786130我理解DDD的价值在于 1. 把职责思考清楚,边界划分相对清楚一些,能够降低耦合度,复杂度; 2. 能够把一些能力沉淀下来,进行复用。2022-05-0715
- 张新亮DDD很难落地,大致有几个原因: 1、DDD落地需要观念的转变,而大多数程序员都还是SSM的拥趸。 2、大多数课程又都是从战略设计开始讲,这又是产品思维,也是大多数程序员不具备的。 3、有些人以需求紧急实现困难为借口,拒绝学习新东西,不了解的东西就使劲摸黑,这帮傻X也是阻碍进步的绊脚石。 所以,程序员要想真正学会DDD,得先从战术开始,先从代码的重构开始,从细节着眼逐步放大。 1、先重构一个类,从贫血模型改为充血模型 2、再重构一个模块,把业务代码和技术代码分离,把分散在各个包的业务代码聚合在一起,形成聚合。 3、重构整个项目,使用CQRS或六边形架构 这样一个项目做下来,整个过程就清晰了2024-02-21归属地:北京
- Elroy我认为 DDD 有很多隐性价值: 提高产研团队的协同效率(统一语言、共同建模); 减少团队间的耦合(模块和团队的边界划分更合理); 提高新服务的开发效率(融入DDD的开发规范、项目代码骨架); 对团队成长也很有帮助(领域知识的传承和沉淀、重视设计质量、重视思考和抽象能力、提升业务研发人员的成就感);2022-11-01归属地:北京
- 不要挑战自己的智商超级用心的一课2022-10-27归属地:美国
- Mr.Tree领域可以是一个业务过程,也可以是整体业务过程的细分子域,换个角度就是用适合的技术手段满足业务需求,将一个整体拆分为一个一个的界限上下文就是将复杂的东西细分,根据各个界限上下文绘制流程图,将每个流程清晰的展现出来,这样就从一个整体到细节的拆分,也能找到各个界限上下文之间的关系,感觉似乎有一点理解了皮毛,但是又似乎吃的是冰淇淋,眼前是一座冰山,结合自身工作再细嚼慢咽一番2022-08-20归属地:四川
- ~风铃~怎么感觉熟悉了业务,根据经验就能拆分,好像不用DDD。可能在不熟悉业务的情况下要划分服务,用DDD就有用。2022-05-14
收起评论