DDD 到底是银弹还是垃圾

每过一段时间，就会有人跳出来批判 DDD，这东西到底是垃圾还是银弹？

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

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

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

所以你觉得我是要批判么？那倒不是。

在某某司工作期间，到离职前，我把市面上所有 DDD 相关的书全部看了一遍。对其理论体系进行了完整的了解，可以说这套理论还是有些用处的，DDD 的理论诞生时间比较早，微服务的趋势是后来才爆发的。但微服务刚开始没有明确的拆分指导，人们发现 DDD 里的 bounded context 好像看着正好和服务的粒度是可以做个对应的，DDD 就成为了很多公司做业务的绝对主流方法论。

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

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

不过作为一个矜持的技术人员，我们在批判方法论的时候，还是应该要先对敌人有一些了解。

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

战术设计与战略设计

整个 DDD 的