php充血模式技巧_为什么用了 DDD 往后代码更难解了

在某某公司干活的时候，有一批人声称要用 DDD 改造老旧系统，彻底办理核心流程规模化之后，项目难以掩护的问题。
之前某篇文章里的这张图，便是在用 DDD 做项目重构之前的烂摊子：

大家都很聪明，聪明到末了没人知道这新需求到底该往哪里写了。
架构师们聚在一起学习 DDD 精神，产出学习报告，大半年过去，终于出了一些成果，有些子项目完成了用 DDD 进行的重构，年底可以拿来在酒会上邀功了，这下我们跟上了业界业务开拓的主流方法论，可喜可贺，可喜可贺啊。

年末的时候部门内匿名提问的小纸条却向架构师们发直球：“ 为什么用了 DDD 往后，代码更难懂了 ？”，当时引得各位 DDD 推手尴尬无比，只能搪塞过去。

以是你以为我是要批驳么？那倒不是。

在某某公司事情期间，到离职前，我把市情上所有 DDD 干系的书全部看了一遍。
对其理论体系进行了完全的理解，可以说这套理论还是有些用途的，DDD 的理论出身韶光比较早，微做事的趋势是后来才爆发的。
但微做事刚开始没有明确的拆分辅导，人们创造 DDD 里的 bounded context 彷佛看着恰好和做事的粒度是可以做个对应的，DDD 就成为了很多公司做业务的绝对主流方法论。

虽然很多技能职员不爱听，但是技能利害和商业成败实在没什么一定的联系。
同样的，方法论的对错和项目的成功与否也没有一定的关系。
很多大公司做业务的人出来讲他们的技能方法论，这些人可能连自己的项目为啥成功都不一定知道，你指望能对你的场景产生直接帮助那可能是想多了。
只是当听个乐，得个借鉴那可能还没什么问题。
真确当金科玉律去实行，那撞一头包也正常。

DDD 和其它的工程方法论一样，没有办法证伪。
放眼望去，纯粹堆砌的人肉电池，不用 DDD 的项目也那么多成功的，大家的屁股还是在随着公司的市值跑，哪家公司市值涨到中国第一了，那他们的技能就牛逼，这叫看市值决定代价不雅观。
如果一家公司靠 996 成功了，那 996 便是商业致胜的法宝，不学你就掉队了。
屁股可以决定脑袋嘛。

不过作为一个自持的技能职员，我们在批驳方法的时候，还是该当要先对仇敌有一些理解。

以是这一篇，我就大略带你们看看 DDD 那些鬼名词都是什么意思。

全体 DDD 的方法论可以划分为两个大模块，战术设计、计策设计。
这个你顾名思义，战术是小，计策是大。

现在很多校招程序员可能或多或少都会碰到一些问题 OOP 方面的口试题，比如三大特性五大原则之类的， 这些原则是设计项目的时候可以参考的原则， DDD 的战术设计便是在单模块上的各种命名规则和设计方法 。
只不过 OOP 这些原则的发明人(严格的说该当是汇总人)是 uncle bob，便是 《clean code》，《clean architecture》 的作者，这位白胡子爷爷大概率是和 DDD 社区是尿不到一个壶里的，以是 《clean architecture》 这本书里只字未提 DDD。

公司的业务要怎么分派给不同的人 bu(部门)去完成，这个一样平常是公司 CTO 或者 GM 要做的事情， 部门内的项目要怎么分，哪些组做哪些事情。
这是计策设计的范畴 。
DDD 声称计策设计也是要有方法的。
这部分也是很多程序员认为最没用的一部分，我们后面来批驳一下这些程序员。

战术设计是纯技能范畴的东西，最让人头痛的便是里面的名词。

血虚模式和充血模式：DDD 推举你用充血模式写代码，也便是按照 OOP 的办法去做抽象，然后把行为挂在工具上，而不因此纯过程式 的方法去写代码。
所谓的充血，便是工具本身有很多关联的行为，而不但是一个纯挚的数据库的表的字段映射。
DDD 声称的充血模式的上风是，大部分的行为被封装到了工具内部，这样我们在阅读流程代码的时候，是一览无余的，直接能看到 step 1，step 2，step 3。
但实际上纵然我们不用 OOP 来组织行为，一样可以把不同的业务 step 做好封装和复用。
有些公司的做事粒度拆得特殊细，比如只有 5000-10000 行代码，在 DDD 里声称的充血模式的上风没有那么明显。

值工具和实体：这个也挺离谱的，值工具便是纯粹的数值、文本类型，比如：

type person struct { age int name string}

便是指工具，如果我们给这个 person 加一个 id，让它能表示 person 的唯一性了；

type person struct { id int age int name string}

那它便是实体了。

这两个观点只是给我们日常用的工具们进行了一个大略的分类，没什么大用途。

聚合根：DDD 所谓的聚合根是事务粒度的 entity，也便是说，如果我们对 db 进行存取，那么我们就须要有一个聚合根，如果在一个事务里须要操作多张表，那么就须要给多张表关联一个单独的聚合根。

聚合根本可以由一个 entity 组成，也可以由多个 entity 组成，便是你完成一个任务 db 事务的时候有多少关联的工具 ，那可能就有多少在同一个聚合根下面的 entity。

六边形架构：这个所谓的六边形架构，便是除了业务以外的所有外部变革都抽象成 adapter interface 做适配。
如果你轻微理解一点点点依赖反转，那该当知道怎么样去做这种抽象。
如果你一点都不理解，那我建议你去看看 go-micro 的代码。
如果看不懂，建议还是尽早转行吧~

六边形架构这东西紧张是名字实在起得太奇怪，在 《clean architecture》那本书里，uncle bob 也给过一张图：

《evolutionary architecture》这本书出自造词大本营 thoughtworks 的员工之手，里面有一个 plugin architecture，便是有些人特殊喜好说的插件化架构：

Repo Pattern：DDD 理论认为我们业务项目的存储这一层是可能常常变革的，以是就专门存储层的 interface 设计单独拿出来，称为 Repo Pattern，这东西实在没啥可说的，find，getlist，save，你只要有一点点 orm 履历，里面有啥接口该当自己都可以默写出来。

事实是在 2021 年，我们的存储系统基本是不太可能做切换的了，纵然切换，那些新兴的社区存储系统也会支持 MySQL 协议，根本举动步伐想要侵入代码，那大略是大逆不道啊。

领域事宜：实在便是做高下游解耦的 kafka message，我们用 domain event 显得会更洋气一些。

领域做事：Domain service，顾名思义，你认为是自己部门或者组内的局部 api gateway 也是可以的。

综上，如果你是在大公司一线事情了两三年的程序员，上面这些东西该当立时就能理解，没有啥值得说的。
如果是为了去架构师大会上秀一秀，你总得包装一下让自己显得没那么土吧？

Domain：领域，你们公司是干啥的，你都不知道吗？

Core Domain：你们公司的卖货的，那卖货便是你们与其它竞争对手的关键竞争环节。
这便是核心域，便是核心业务，为啥聪明人都往核心业务挤？核心业务的汤也比边缘业务的饭好啊。

SubDomain：你们公司的卖货的，但是用户没法付钱，那也没法干，支付便是子领域。

Supporting Domain：你们公司是卖货的，但是客户想看一些指标，你总得有系统能支持吧？可能便是些写写 SQL 的系统。
支持域。

Generic Domain：你管你们公司干什么呢？员工的在职离职，人为发放总得有系统能支持吧，这些便是通用域。

除了第一个 Domain ，别的四个 domain 主要性逐级递减，递减的意思是，如果公司要裁员，那是从下面往上面裁。

前面我说有些程序员以为 DDD 计策设计没用，你连自己所在的组，从事的事情职责对付公司来说重不主要都不清楚，那被裁的时候也别哭哦。

统一措辞：这个就更好理解了，比如跳水这个词，你说跳水的时候指的是这个：

而你同事说跳水的时候指的是这个：

这里你们聊的是事情，那解释你们一定不是在同一个高下文里事情，可能你们俩一个在体育赛事部门，另一个可能是在金融部门， DDD 认为可以用统一措辞来进行领域划分事情。
划分后在同一个高下文内，同一个名词大家说出来意思同等。
这便是 Bounded Context， ain。

既然拆分了，如果我们还在同一个 domain 内，那完成业务流程是须要协作的，这个不同 Context 的协作办法就叫 Context Maps 或者 Integration Type。

名词很恶心，但详细的方法就两种，两个微做事要么通过 RPC 通信，要么通过 MQ 通信。

如果通过 RPC 通信，那 callee 一样平常是 caller 的爹，很多时候 callee 挂了是要影响 caller 的(当然也有熔断之类的方法避免一起去世)。

通过通过 MQ 通信，那上游一样平常是下贱的爹，由于上游一个重构，下贱们可能就都炸了，终极同等都是屁话，多少公司的终极同等都是靠人肉修的。

这种爹和儿子的关系便是 Conformist 。
如果爹能多考虑一下儿子的需求，那便是 Customer-Supplier 关系，毕竟顾客名义上还是上帝。
如果跨系统有一些须要共享的定义，比如公司里的业务分类，可能大家都要从某个别系的 PHP 文件里解析出来在自己的系统里去用，那这时候可能得去利用别人的代码，这种叫 Shared-Kernel，Kernel 一改，大家一起去世。

末了，有时候我们可以用一个叫 ACL 的东西拦住上游的一些修正对我们的业务逻辑侵入：

防腐层：Anti-Corruption-Layer，便是我要把外部系统的变革拦截在对接层，不要让别人的屎甩到我身上。

讲到这里，基本的观点我们已经都过一遍了，你要说 DDD 一点用途都没有，那我也是不同意的，至少看完了这些书，我知道去哪里能赚到更多的钱了。

原文链接：https://mp.weixin.qq.com/s?__biz=MjM5NDM4MDIwNw==&mid=2448836593&idx=1&sn=bd223c8ff27fb3c97455621e0ad21a60&utm_source=tuicool&utm_medium=referral

标签：便是公司