10x程序员工作法
郑晔
火币网首席架构师,前ThoughtWorks首席咨询师 ,TGO鲲鹏会会员
立即订阅
7978 人已学习
课程目录
已完结 56 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 程序员解决的问题,大多不是程序问题
免费
思考框架 (1讲)
01 | 10x程序员是如何思考的?
以终为始 (11讲)
02 | 以终为始:如何让你的努力不白费?
03 | DoD的价值:你完成了工作,为什么他们还不满意?
04 | 接到需求任务,你要先做哪件事?
05 | 持续集成:集成本身就是写代码的一个环节
06 | 精益创业:产品经理不靠谱,你该怎么办?
07 | 解决了很多技术问题,为什么你依然在“坑”里?
08 | 为什么说做事之前要先进行推演?
09 | 你的工作可以用数字衡量吗?
10 | 迭代0: 启动开发之前,你应该准备什么?
答疑解惑 | 如何管理你的上级?
划重点 | 关于“以终为始”,你要记住的9句话
任务分解 (11讲)
11 | 向埃隆·马斯克学习任务分解
12 | 测试也是程序员的事吗?
13 | 先写测试,就是测试驱动开发吗?
14 | 大师级程序员的工作秘笈
15 | 一起练习:手把手带你分解任务
16 | 为什么你的测试不够好?
17 | 程序员也可以“砍”需求吗?
18 | 需求管理:太多人给你安排任务,怎么办?
19 | 如何用最小的代价做产品?
答疑解惑 | 如何分解一个你不了解的技术任务?
划重点 | 关于“任务分解”,你要重点掌握哪些事?
沟通反馈 (12讲)
20 | 为什么世界和你的理解不一样
21 | 你的代码为谁而写?
22 | 轻量级沟通:你总是在开会吗?
23 | 可视化:一种更为直观的沟通方式
24 | 快速反馈:为什么你们公司总是做不好持续集成?
25 | 开发中的问题一再出现,应该怎么办?
26 | 作为程序员,你也应该聆听用户声音
用户故事 | 站在前人的肩膀上,领取属于你的高效工作秘籍
27 | 尽早暴露问题: 为什么被指责的总是你?
28 | 结构化:写文档也是一种学习方式
答疑解惑 | 持续集成,一条贯穿诸多实践的主线
划重点 | 一次关于“沟通反馈”主题内容的复盘
自动化 (12讲)
加餐 | 你真的了解重构吗?
29 | “懒惰”应该是所有程序员的骄傲
30 | 一个好的项目自动化应该是什么样子的?
31 | 程序员怎么学习运维知识?
32 | 持续交付:有持续集成就够了吗?
33 | 如何做好验收测试?
34 | 你的代码是怎么变混乱的?
35 | 总是在说MVC分层架构,但你真的理解分层吗?
36 | 为什么总有人觉得5万块钱可以做一个淘宝?
37 | 先做好DDD再谈微服务吧,那只是一种部署形式
答疑解惑 | 持续集成、持续交付,然后呢?
划重点 | “自动化”主题的重点内容回顾汇总
综合运用 (7讲)
38 | 新入职一家公司,怎么快速进入工作状态?
39 | 面对遗留系统,你应该这样做
40 | 我们应该如何保持竞争力?
答疑解惑 | 如何在实际工作中推行新观念?
划重点 | “综合运用”主题内容的全盘回顾
总复习 | 重新审视“最佳实践”
总复习 | 重新来“看书”
结束语 (1讲)
结束语 | 少做事,才能更有效地工作
10x程序员工作法
登录|注册

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

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

微服务

大部分人对微服务的了解源自 James Lewis 和 Martin Fowler 在 2014 年写的一篇文章,他们在其中给了微服务一个更清晰的定义,把它当做了一种新型的架构风格。
但实际上,早在这之前的几年,很多人就开始用“微服务”这个词进行讨论了。
“在企业内部将服务有组织地进行拆分”这个理念则脱胎于 SOA(Service Oriented Architecture,面向服务的架构),只不过,SOA 诞生自那个大企业操盘技术的年代,自身太过于复杂,没有真正流行开来。而微服务由于自身更加轻量级,符合程序员的胃口,才得以拥有更大的发展空间。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(18)

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

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

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

    在限界上下文中统一术语的认识,而不是花更多精力让所有参与者都统一术语,其实是非常务实的做法

    作者回复: 多谢分享!

    2019-04-05
    6
  • 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
    5
  • Lyam📵
    这篇真的太棒了!正如微服务里的两句话“微服务是双刃剑,拆得越细,优势越明显,缺点也越明显”,“要用好微服务,最好别做微服务”。深刻了!

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

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

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

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

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

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

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

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

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

    2019-07-01
    3
  • ownraul
    一个很重要的点是, 即便没有DDD的概念, 我们自己的系统也一定需要有自己的业务模型, 任何需求的变化一定都是需要在这个业务模型上最先体现变化出来, 外部和我们系统的交互, 一定是先翻译转换为我们自己的内部模型, 然后再进行逻辑处理, 否则外部依赖源一旦增多, 很多转换会把整个系统代码污染到不想再维护的

    作者回复: 核心模型是关键,DDD是方法。

    2019-04-17
    3
  • desmond
    "什么,讲了这么多,让我不用微服务?"
    "及时止损"对很多人来说,是不可接受的。

    作者回复: 沉没成本不是成本,懂点经济学很难得。

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

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

    2019-04-06
    3
  • 老师说的很有道理,我们经常会忽视基本面去谈理想和目标。DDD是一套思维体系,虽然市面上有很好的资料给予我们借鉴,但怎么去定义自己的领域、子域的边界及彼此的交互关联不一而足。周围也有人为微服务而微服务,真要是落在纸面上却无从入手,背后是抽象能力还不足以支撑期望。另一方面是避免过度设计,就如上讲所说淘宝也是演进来的,DDD也不是一步到位的,需求在变要求在变,设计也就需要跟着变。总的说来我觉得就是需要提升抽象能力和做好持续改进的准备,不能操之过急也不能局限于眼下。
    2019-04-06
    2
  • Calvin
    不错的文章,期待后面更多DDD方面的实践例子。
    实际工作中很常见到的是做微服务了,但很时候微服务没有很好的模块化,结果还是往big ball of mud的方向写。

    作者回复: 只可惜专栏已经接近尾声,很难再深入细节讨论了。

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

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

    2019-06-23
    1
  • 刘晓林
    郑老师,有个问题请教下:微服务应该不应该共享一个所谓的公共二方库common。比如一些枚举类,工具类,DTO类放入这个common库中。如果用common类,那么就增加了服务之间的耦合度,如果不使用,那么又会出现同一个类重复定义的问题。
    2019-10-31
  • @holddie.com
    DDD 是一本武林秘籍,屠龙宝刀,分场合使用
    2019-08-22
  • 陈斯佳
    做为一个运维,表示没看懂😭 看来离程序员还有一段很长的距离……
    2019-06-21
  • whhbbq
    多谢老师推荐书单。
    之前使用过DDD的防腐层设计,为了减少模块之间的耦合,隔离变化。其他概念还需要深入学习,并在实际项目中实践。
    2019-05-08
收起评论
18
返回
顶部