数字市场法案|为什么用了 DDD 以后，代码更难懂了？欧盟|苹果|亚马逊

文章图片

文章图片

文章图片

每过一段时间，就会有人跳出来批判 DDD ，这东西到底是垃圾还是银弹？
在某某公司干活的时候，有一批人声称要用 DDD 改造老旧系统，彻底解决核心流程规模化之后，项目难以维护的问题。之前某篇文章里的这张图，就是在用 DDD 做项目重构之前的烂摊子：

大家都很聪明，聪明到最后没人知道这新需求到底该往哪里写了。架构师们聚在一起学习 DDD 精神，产出学习报告，大半年过去，终于出了一些成果，有些子项目完成了用 DDD 进行的重构，年底可以拿来在酒会上邀功了，这下我们跟上了业界业务开发的主流方法论，可喜可贺，可喜可贺啊。
年末的时候部门内匿名提问的小纸条却向架构师们发直球：“为什么用了 DDD 以后，代码更难懂了？” ，当时引得各位 DDD 推手尴尬无比，只能搪塞过去。
所以你觉得我是要批判么？那倒不是。
在某某公司工作期间，到离职前，我把市面上所有 DDD 相关的书全部看了一遍。对其理论体系进行了完整的了解，可以说这套理论还是有些用处的， DDD 的理论诞生时间比较早，微服务的趋势是后来才爆发的。但微服务刚开始没有明确的拆分指导，人们发现 DDD 里的 bounded context 好像看着正好和服务的粒度是可以做个对应的， DDD 就成为了很多公司做业务的绝对主流方法论。
虽然很多技术人员不爱听，但是技术优劣和商业成败其实没什么必然的联系。同样的，方法论的对错和项目的成功与否也没有必然的关系。很多大公司做业务的人出来讲他们的技术方法论，这些人可能连自己的项目为啥成功都不一定知道，你指望能对你的场景产生直接帮助那可能是想多了。只是当听个乐，得个借鉴那可能还没什么问题。真的当金科玉律去执行，那撞一头包也正常。
DDD 和其它的工程方法论一样，没有办法证伪。放眼望去，纯粹堆砌的人肉电池，不用 DDD 的项目也那么多成功的，大家的屁股还是在跟着公司的市值跑，哪家公司市值涨到中国第一了，那他们的技术就牛逼，这叫看市值决定价值观。如果一家公司靠 996 成功了，那 996 就是商业致胜的法宝，不学你就落后了。屁股可以决定脑袋嘛。
不过作为一个矜持的技术人员，我们在批判方法的时候，还是应该要先对敌人有一些了解。
所以这一篇，我就简单带你们看看 DDD 那些鬼名词都是什么意思。
战术设计与战略设计整个 DDD 的方法论可以划分为两个大模块，战术设计、战略设计。这个你顾名思义，战术是小，战略是大。

战术设计指的就是单模块级的设计，基本都是纯技术范畴的东西，只DDD 给代码命名和模块设计给出了一些指导方法
战略设计指的是大项目的模块拆分，这个和一线程序员关系不大，主要是公司那怎么在 bu 之间切蛋糕， bu 内怎么在 team 之间分赃

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