37 | 先做好DDD再谈微服务吧，那只是一种部署形式
郑晔
该思维导图由 AI 生成，仅供参考
你好，我是郑晔。
在“自动化”模块的最后，我们来聊一个很多人热衷讨论却没做好的实践：微服务。
在今天做后端服务似乎有一种倾向，如果你不说自己做的是微服务，出门都不好意思和人打招呼。
一有技术大会，各个大厂也纷纷为微服务出来站台，不断和你强调自己公司做微服务带来的各种收益，下面的听众基本上也是热血沸腾，摩拳擦掌，准备用微服务拯救自己的业务。
我就亲眼见过这样的例子，几个参加技术大会的人回到公司，跟人不断地说微服务的好，说服了领导，在接下来大的项目改造中启用了微服务。
结果呢？一堆人干了几个月，各自独立开发的微服务无法集成。最后是领导站出来，又花了半个月时间，将这些“微服务”重新合到了一起，勉强将这个系统送上了线。
人家的微服务那么美，为什么到你这里却成了烂摊子呢？因为你只学到了微服务的形。
微服务
但实际上，早在这之前的几年，很多人就开始用“微服务”这个词进行讨论了。
“在企业内部将服务有组织地进行拆分”这个理念则脱胎于 SOA（Service Oriented Architecture，面向服务的架构），只不过，SOA 诞生自那个大企业操盘技术的年代，自身太过于复杂，没有真正流行开来。而微服务由于自身更加轻量级，符合程序员的胃口，才得以拥有更大的发展空间。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
微服务架构在后端服务开发中备受关注，然而实践中却面临诸多困难。本文指出，微服务的关键在于业务划分，而领域驱动设计（DDD）提供了解决方案。DDD强调贴近业务、通用语言和限界上下文的重要性，帮助团队从技术转向业务。正确划分微服务的关键性，限界上下文应成为独立的部署单元，避免大量耦合。此外，文章提到了分布式对象的第一定律：不要分布对象，强调先按照限界上下文划分模块，等待各自独立演化后再考虑微服务拆分。因此，建议在谈微服务之前，先做好DDD，将业务划分清楚，才能更好地实现微服务架构。文章还介绍了DDD的发展历程和推荐学习方法，强调学习DDD的重要性。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《10x 程序员工作法》，新⼈⾸单¥68
《10x 程序员工作法》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(25)
- 最新
- 精选
段启超我是今年年初的时候接触到领域驱动设计的，看Eric的《领域驱动设计》确实给了我非常大的启发，给我目前工作中遇到的问题指明了方向。DDD改变了我思考问题的方式，让我把关注点回归业务，而不是一开始就去考虑技术的是实现问题。尤其是限界上下文的概念，让我明白了一直在搞，却总是搞不好的微服务到底是哪儿出了问题。 但是目前的困境是：想在公司内推行DDD，阻力真的很大，首先是很多人对DDD没概念，需要一定的学习成本，二是团队间相互隔离，沟通成本很高，起码的通用语言都很难达成。在上次迭代中，很多时间都花在弥补因为沟通不畅导致的扯皮中了，最后就是功能虽然实现了，代码却早已经改成了大泥球。还有就是不顾长远的赶进度，实现功能是首要的，领域模型就成了没有人去做，也没有时间去做事情。作者回复: 不要推 DDD，推行一个概念总是困难的。用具体问题来说事，推行人心目中有目标就好，具体问题大家总是接受的，把问题解决了，再来和大家介绍思路。
2019-04-05232
西西弗与卡夫卡领域驱动设计中把术语在不同领域中的差异提到了比较高的程度。这其实是日常工作中非常常见的问题，同一个名词，不同人的理解是不同的，在不同业务中的含义也不同。最近正在构建组织架构服务，不同人想的就不一样。行政/HR想的是在企业IM里看到的是组织架构，实际上是按业务线划分。财务想的是，凭证进财务系统的时候，需要按照不同公司，这又是一个组织架构。业务团队之间会产生协作，比如都是为用户增长，参与协作的人又会形成某种组织架构。 在限界上下文中统一术语的认识，而不是花更多精力让所有参与者都统一术语，其实是非常务实的做法作者回复: 多谢分享！
2019-04-0520
LYy多谢老师推荐的书单 之前直接看<领域驱动设计>没看明白作者回复: 有了骨架统筹起来，再来学一遍。
2019-04-0514
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-1012
enjoylearning说的好，领域驱动设计确实是进入微服务的前置条件，除了设置边界上下文，还要划分子域，实现领域驱动设计那本书看了后，其实还是要看一下Eric的那本书，一个是道，一个是术。作者回复: 你已经有了基础，可以发力了！
2019-04-0512
Sam_Deep_Thinking如果是使用hibernate ，实施起DDD，会容易一些。但是互联网公司大部分用mybatis，毕竟sql得完全自己控制才好。作者回复: 这种思路就是典型的被工具绑架的思路，一个正常的做法是按照DDD建模，然后用mybatis实现这些定义好的接口。
2019-06-2310
zapup这篇真的太棒了！正如微服务里的两句话“微服务是双刃剑，拆得越细，优势越明显，缺点也越明显”，“要用好微服务，最好别做微服务”。深刻了！作者回复: 欢迎把它分享给你的朋友
2019-04-068
风翱公司说我们的开发方式是敏捷开发，实际上只是使用了一些敏捷开发的方法，只有遵守敏捷开发的价值观和原则，才能算是敏捷开发。微服务也是一样，不是说拆分成多个服务去部署，就叫做微服务。也不是采用市面上常用的微服务框架，就是微服务了。作者回复: 招数好学，内涵难成。
2019-04-067
行者感触很深，之前我们在开发一个新项目中，3个人拆了10+个微服务，维护、排查问题都很麻烦；之后服务减少到3个才好很多；微服务很好，但是我们要明白为什么要微服务，以及微服务会带来哪些问题，千万不要一上来就微服务。 血淋淋的教训！作者回复: 知其然，不知所以然，是陷入深坑的开始。
2019-04-057
川子老师有没有计划开辟一个专讲ddd的专栏作者回复: 我在考虑软件设计。
2019-07-0136
收起评论
