DDD到底是不是毒瘤？

牛B的人物，早已经厌倦了中英文混杂，他们更进一步，使用中英文缩写，对普通人进行降维打击。更厉害的，造就新的名词，并科普出去。

有几项技术，我从心底里鄙视和厌恶，但每次在技术方案中，都默默的把它们加进去，而且给足了它们分量。因为它们对于方案的成功与否，起着重要的概念性指导作用。

它们就是中台、低代码，以及DDD。这三个不同领域中的技术，肩负着同样的责任，那就是往死里忽悠。这三个词，很伟大，它们有一个共同点，都是很容易说服非技术但能决策的人员，然后向下铺开，非常具有营销型，是职业经理人和CTO的最爱。也是咨询类公司的最爱。

这些玩意儿，有的可以忽悠大公司，有的可以忽悠小公司，反正谁也别想逃掉。

但毒瘤如果能够为我们带来利益，当然也要拥抱。不要那么死板嘛。

当妖风袭来，比起关上窗子，我们要拥抱它，要投其所好！为什么有的人工资高，有的人升的快！有的人成为了大师！要从根本上想想原因。

概念能够升华体系

你知道么？越是职位高的人，越容易喜欢虚无缥缈的东西。拿古代的皇帝来说，有很多期望与神仙相会的，就被方士骗的死去活来。即使到最后知道被骗了，也只能偷偷的把消息封锁起来。最近看《资治通鉴》，就发现了很多这样的案例。

一来，是他们真的有这种需求；二来，是怕这些事被曝光了丢脸，只能咬牙坚持下去。

地球上没有新鲜事，放到软件行业也一样。当我们把一件东西给神化，赋予它某些超自然的能力，它就能在方士的路上越走越平坦。

如何神化？抓痛点、谈愿景、搞方法论，一般就能够销售成功。

当然，销售成功只是第一步，我们还要避免失败，避免被秋后算账。所以，我们需要把决策者的积极性调动起来，让他认识到自己的不足，羞于承认自己的弱点，我们就算落稳脚步了。只要决策者上了船，他就会想方设法美化它，争取更多的资源，让更多的人上船。

为什么互联网黑话生命力强劲，就是因为它能忽悠，能够升华你的思想，而不是空洞洞的代码。

我这里举个例子。

有一家公司，由于研发的人数有限，但是活儿很多，分散在多个系统之间。研发部门研究出来的结论是：要聚焦，集中力量到核心系统上。怎么办？不能在PPT上干巴巴的写上聚焦两个字吧，那显得多LOW。

思来想去，突然灵机一动。要不，我们造点名词吧。按照级别，分它个CVP系统、IVP系统、EVP系统。这样，一下子逼格就上升了不少。

看不懂这些名词？看不懂就对了，因为这是我造的，要的就是看不懂这种效果。

看看下面这张图，我们甚至可以赋予它属性，把系统归类到这三类之中。

重要的是，业务系统的聚焦，摇身一变，成为了CVP的重点建设。哈哈，比起一句话就完事的决策，我们这下可以聊很久了。

“教你怎么说话十分钟，等于什么都没说”。这是一种非常重要的能力。

那么，我们就来看一下，这些技术到底是什么？为什么是毒瘤？为什么要拥抱它们。

D不D的D的，有啥区别么

所谓领域驱动，就是根据需求设计系统，这句话本来就是废话。

有Demo代码没？

所有的文章下面，都充满了这样的发问。如果说DDD层只是战略上有用，那它就不应该进入程序员视野，它应该是需求分析师的玩具。DDD应该学学TOGAF、COBIT、CGEIT之类的培训，把眼光放在战略布局上，不要老是想着革程序员的命，搞什么战术。

你要是专心搞搞业务培训证书，你赚你的钱我做我的架构设计，咱们井水不犯河水。但你要把触角伸到我的领域，就会招来像我这样的喷子。

DDD正确的打开方式，就是拥抱它的战略阶段，完全扔掉它的战术阶段。这样做，你会活的很舒坦。原谅我使用“限界上下文”这样的名词来解释一下：你只要把我的服务边界划分清楚了，你管我后面是怎么实现呢，设计模式和架构模式，我的工具箱多的很，并不缺CQRS、事件溯源这样的名词。

DDD的概念最早来源于2004年，这么多年没火，没有标准落地，不是没有原因的。最近几年，有些人发现了技术名词的贫瘠，重新捡起了它，希望它能继续为KPI效力。

我曾痴迷DDD，被它的美好愿景折磨的兴奋无比。买了网课，买了书籍，到最后发现它在浪费我的时间。我恨它。恕我直言，一个难度高，落地难的技术方案，根本没有资格让人分割精力去了解它。

不好意思，没有路转粉。

首先，搞DDD的，都是些卷中卷公司，它不像微服务技术一样，能够找到大量落地的方案。实际上，你几乎找不到任何有价值的参考示例，更别说这些示例之间还相互打脸。它就像是圣经一样，给你说什么是对的，但怎么做，全靠你悟。

为什么你干不了DDD，你的团队干不了DDD？DDD给出了三个主要原因。

对团队的要求较高。画外音，你做不好是你的团队不行
只有复杂的业务使用DDD才能见效。那什么是复杂呢？并没有定论。话外音，你觉得不好用，那是你的业务不够复杂
虽然你用不了DDD，但其中的思想，还是值得借鉴和思考的。画外音，我是万金油，不会让你白学

没有人会承认自己的团队不行，没有团队会承认自己的业务简单，没人能忍受自己的投入就真的肉包子打狗了。DDD通过几个让你不能打脸的理由，瞬间将你绑在了一起。

2020年，花了整整三个月时间，有幸拜读了《实现领域驱动设计》这本书，对其深厚的文字运用水平惊叹拜服。以后，即使一个简单的CRUD项目，我也知道文档应该怎么写了，这本书就是非常好的案例。

你搜一下DDD的文章，不论什么文章，都有一个特点，那就是不能好好的说人话。所有的应用代码，都是一堆无法说服人的垃圾代码。因为开发者和正常的写法一比较，发现自己在找罪受，那为什么要用它呢？

就拿吹的很牛b的六边形架构来说吧。

六边形架构，因为长得像蜂窝，看起来就很靠近绿色的自然界，很高大上。说实话，我到现在都没弄明白六边形架构，八边形架构（没这种东西），三角形架构（没这种东西）之间，到底有何区别，这群名词狂魔为啥选择了6这个数字。

您就直说，复杂的业务逻辑，不应该过多的关注技术等基础设施、但要预留接口就行了，非要整的这么玄乎，一条条蚯蚓一样的线从那腐烂的六边形上辐射出来。觉得很美么？或许老板真这么觉得，因为它像彩虹一样的名词轮，确实能唬住一群蹉B。

不要说ServiceMesh的数据平面和控制平面分割，是靠DDD指导的哦，虽然它概念上靠的上。

下图是google搜索Hexagonal Architecture出现的一张图。

哎吆，六边形呢？这图怎么整了个10边形？那还是六边形架构么？您忽悠小孩子呢？当我不识数？什么，你又把它叫做洋葱头架构，它们不是一个东西？这样的误解在DDD中比比皆是，我也不想解释，因为它们都是短话长说。这说明了它是一门全面的忽悠方法论，是靠堆概念和黑话起家的，宣传者也不合格。

整个DDD这一套概念，价值观就有问题。或者说作者的本意或许是好的，面向的是复杂业务。结果让这群宣传者和培训一捣鼓，就成了解决问题的必要手段。

但是不好意思，您连起码的顺畅交流都没整好，没资格教别人做架构。

尴尬局面

让人觉得尴尬的是，真正需要DDD的人，并不认同它；不需要DDD的人，被强迫认同它。

DDD最大的价值是梳理业务性需求，将不同的业务领域划分出来，并形成领域之间的接口交互。说个实话，我见过很多咨询公司的大佬，他们对这种想要通吃的方法论嗤之以鼻，更倾向于使用TOGAF之类老牌的业务梳理方法。但条条道路通罗马，最终的领域划分还是能够达成一致。

这些梳理的过程，大部分是业务专家，以及系统架构师的范畴。他们的工作成果，将作为输入输出到技术团队实现。他们需要DDD，但他们并不用。

相比较而言，DDD的战术阶段，毫无价值而言。比如，把数据汇总到宽表或者大数据中心，形成数据“中台”提供交易域、管理域、查询域的分离，我并不需要知道什么CQRS的概念，也能工作的很好。至于实体充血不充血，我本来就是微服务了，业务粒度本来就很小了，要怎么写是我的自由，改造也是我自己的成本，我并不需要按照你那一套来。谈业务和技术的沟通？不好意思，不能沟通而去做业务的团队，我还没见过。

工程师被决策层强迫使用DDD战术书写业务，结果代码更乱，更改更加频繁。但是DDD说，不好意思，不是我的错，是你团队不行。

道理是这个道理，但在现实中，还是有人吹嘘、甚至使用这个东西去改造代码。《微服务架构模式》这本书，甚至有事件溯源和CQRS两个章节，去专门讲解DDD的一些落地的内容。这叫做大师毒害了大师，当然也叫做相互扶持。

恕我直言，如果你信了这些鬼话，大概率会把项目带入死亡。尽信书不如无书，架构是一种权衡，并没有通吃的指导思路。你可以参考，可以思考，但就是不能照搬，因为每个公司的技术前提都不一样。

话虽如此，但当一些概念被吹嘘起来的时候，你不去拥抱它，反而会产生问题。软件行业有两个难题，一个是怎么把复杂的事情简单的汇报，另外一个就是把简单的东西搞复杂。对于前者，主要是描述你构想的可行性。而对于后者，主要的目的就是让人觉得很高大上，很主流，越晦涩越好。前者脚踏实地，后者口吐莲花。

而后者的功效，显然要比前一种有效得多。让人听上去感觉很牛x，但是听不懂，可以获得掌声，也可以体验高高在上的感觉。没人会承认自己的智商不在线，你需要激起这些人的活力。只要有人认同，就可以产生利益。

有些概念，有些人，并不是神，但利益共同体，需要他成为神。这玩意也有信徒，你信么？但软件设计的工具，难道不是合适就用，不合适就扔么？为什么会成为信徒？仅仅是因为上船了而已。

朋友们，在一定程度上，DDD这些概念，与比特币之类的概念，并没有什么区别。这就是信仰的魔力，这就是大师的力量啊！

End

只有像我这样诚实的人，才会偶尔喷一喷。然后转身，把DDD写在了自己的方案上。是的，我可以写上，也可以讨论，也可以思维碰撞，但我永远不会轻易用它。

原文链接：https://juejin.cn/post/7024025943668686885

如果你觉的本文对你有帮助，麻烦点赞关注支持一下