10x 程序员工作法
郑晔
开源项目 Moco 作者
53432 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 63 讲
思考框架 (1讲)
10x 程序员工作法
15
15
1.0x
00:00/00:00
登录|注册

37 | 先做好DDD再谈微服务吧,那只是一种部署形式

《领域驱动设计精华》(Vaughn Vernon)
《实现领域驱动设计》(Vaughn Vernon)
《领域驱动设计》(Eric Evans)
战术设计(Tactical Design)
战略设计(Strategic Design)
通用语言(Ubiquitous Language)
建议:先用分模块的方式在一个工程内,让服务先演化一段时间,等到真的觉得某个模块可以“毕业”了,再去开启微服务之旅
分布式对象第一定律:不要分布对象
限界上下文(Bounded Context)
难点:业务划分
定义:一种新型的架构风格
重要作品
核心概念
目的:将业务概念和规则转换成软件系统中概念和规则,降低或隐藏业务复杂性,使系统具有更好的扩展性
提出者:Eric Evans
微服务
领域驱动设计(DDD)
领域驱动设计与微服务

该思维导图由 AI 生成,仅供参考

你好,我是郑晔。
在“自动化”模块的最后,我们来聊一个很多人热衷讨论却没做好的实践:微服务。
在今天做后端服务似乎有一种倾向,如果你不说自己做的是微服务,出门都不好意思和人打招呼。
一有技术大会,各个大厂也纷纷为微服务出来站台,不断和你强调自己公司做微服务带来的各种收益,下面的听众基本上也是热血沸腾,摩拳擦掌,准备用微服务拯救自己的业务。
我就亲眼见过这样的例子,几个参加技术大会的人回到公司,跟人不断地说微服务的好,说服了领导,在接下来大的项目改造中启用了微服务。
结果呢?一堆人干了几个月,各自独立开发的微服务无法集成。最后是领导站出来,又花了半个月时间,将这些“微服务”重新合到了一起,勉强将这个系统送上了线。
人家的微服务那么美,为什么到你这里却成了烂摊子呢?因为你只学到了微服务的形。

微服务

大部分人对微服务的了解源自 James Lewis 和 Martin Fowler 在 2014 年写的一篇文章,他们在其中给了微服务一个更清晰的定义,把它当作了一种新型的架构风格。
但实际上,早在这之前的几年,很多人就开始用“微服务”这个词进行讨论了。
“在企业内部将服务有组织地进行拆分”这个理念则脱胎于 SOA(Service Oriented Architecture,面向服务的架构),只不过,SOA 诞生自那个大企业操盘技术的年代,自身太过于复杂,没有真正流行开来。而微服务由于自身更加轻量级,符合程序员的胃口,才得以拥有更大的发展空间。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

微服务架构在后端服务开发中备受关注,然而实践中却面临诸多困难。本文指出,微服务的关键在于业务划分,而领域驱动设计(DDD)提供了解决方案。DDD强调贴近业务、通用语言和限界上下文的重要性,帮助团队从技术转向业务。正确划分微服务的关键性,限界上下文应成为独立的部署单元,避免大量耦合。此外,文章提到了分布式对象的第一定律:不要分布对象,强调先按照限界上下文划分模块,等待各自独立演化后再考虑微服务拆分。因此,建议在谈微服务之前,先做好DDD,将业务划分清楚,才能更好地实现微服务架构。文章还介绍了DDD的发展历程和推荐学习方法,强调学习DDD的重要性。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《10x 程序员工作法》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(25)

  • 最新
  • 精选
  • 段启超
    我是今年年初的时候接触到领域驱动设计的,看Eric的《领域驱动设计》确实给了我非常大的启发,给我目前工作中遇到的问题指明了方向。DDD改变了我思考问题的方式,让我把关注点回归业务,而不是一开始就去考虑技术的是实现问题。尤其是限界上下文的概念,让我明白了一直在搞,却总是搞不好的微服务到底是哪儿出了问题。 但是目前的困境是:想在公司内推行DDD,阻力真的很大,首先是很多人对DDD没概念,需要一定的学习成本,二是团队间相互隔离,沟通成本很高,起码的通用语言都很难达成。在上次迭代中,很多时间都花在弥补因为沟通不畅导致的扯皮中了,最后就是功能虽然实现了,代码却早已经改成了大泥球。还有就是不顾长远的赶进度,实现功能是首要的,领域模型就成了没有人去做,也没有时间去做事情。

    作者回复: 不要推 DDD,推行一个概念总是困难的。用具体问题来说事,推行人心目中有目标就好,具体问题大家总是接受的,把问题解决了,再来和大家介绍思路。

    2019-04-05
    2
    32
  • 西西弗与卡夫卡
    领域驱动设计中把术语在不同领域中的差异提到了比较高的程度。这其实是日常工作中非常常见的问题,同一个名词,不同人的理解是不同的,在不同业务中的含义也不同。最近正在构建组织架构服务,不同人想的就不一样。行政/HR想的是在企业IM里看到的是组织架构,实际上是按业务线划分。财务想的是,凭证进财务系统的时候,需要按照不同公司,这又是一个组织架构。业务团队之间会产生协作,比如都是为用户增长,参与协作的人又会形成某种组织架构。 在限界上下文中统一术语的认识,而不是花更多精力让所有参与者都统一术语,其实是非常务实的做法

    作者回复: 多谢分享!

    2019-04-05
    20
  • LYy
    多谢老师推荐的书单 之前直接看<领域驱动设计>没看明白

    作者回复: 有了骨架统筹起来,再来学一遍。

    2019-04-05
    14
  • Wei
    又一篇解答了我疑惑的一篇好文章! 我之前也是抱着“TDD其实不实用”的观念,老师TDD的章节让我明白了TDD的本质在于架构设计,而架构设计是从具体任务分解而来;关于微服务,我对其理解一直放在ops/tools 方面,现在才明白其本质也是软件结构问题,服务的划分通过DDD, ops/tools只是服务的implementation. 另外提一下2017 年 Domain-Driven Design Distilled 出了Vaughn Vernon 讲解的视频版,现在积极补课中,上一个链接: https://learning.oreilly.com/videos/domain-driven-design-distilled/9780134593449

    作者回复: 多谢补充!

    2019-04-10
    12
  • enjoylearning
    说的好,领域驱动设计确实是进入微服务的前置条件,除了设置边界上下文,还要划分子域,实现领域驱动设计那本书看了后,其实还是要看一下Eric的那本书,一个是道,一个是术。

    作者回复: 你已经有了基础,可以发力了!

    2019-04-05
    12
  • Sam_Deep_Thinking
    如果是使用hibernate ,实施起DDD,会容易一些。但是互联网公司大部分用mybatis,毕竟sql得完全自己控制才好。

    作者回复: 这种思路就是典型的被工具绑架的思路,一个正常的做法是按照DDD建模,然后用mybatis实现这些定义好的接口。

    2019-06-23
    10
  • zapup
    这篇真的太棒了!正如微服务里的两句话“微服务是双刃剑,拆得越细,优势越明显,缺点也越明显”,“要用好微服务,最好别做微服务”。深刻了!

    作者回复: 欢迎把它分享给你的朋友

    2019-04-06
    8
  • 风翱
    公司说我们的开发方式是敏捷开发,实际上只是使用了一些敏捷开发的方法,只有遵守敏捷开发的价值观和原则,才能算是敏捷开发。微服务也是一样,不是说拆分成多个服务去部署,就叫做微服务。也不是采用市面上常用的微服务框架,就是微服务了。

    作者回复: 招数好学,内涵难成。

    2019-04-06
    7
  • 行者
    感触很深,之前我们在开发一个新项目中,3个人拆了10+个微服务,维护、排查问题都很麻烦;之后服务减少到3个才好很多;微服务很好,但是我们要明白为什么要微服务,以及微服务会带来哪些问题,千万不要一上来就微服务。 血淋淋的教训!

    作者回复: 知其然,不知所以然,是陷入深坑的开始。

    2019-04-05
    7
  • 川子
    老师有没有计划开辟一个专讲ddd的专栏

    作者回复: 我在考虑软件设计。

    2019-07-01
    3
    6
收起评论
显示
设置
留言
25
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部