图片来自 包图网
有几项技术，我从心底里鄙视和厌恶，但每次在技术方案中，都默默的把它们加进去，而且给足了它们分量。因为它们对于方案的成功与否，起着重要的概念性指导作用。
它们就是中台、低代码，以及 DDD。这三个不同领域中的技术，肩负着同样的责任，那就是往死里忽悠。
这三个词，很伟大，它们有一个共同点，都是很容易说服非技术但能决策的人员，然后向下铺开，非常具有营销型，是职业经理人和 CTO 的最爱。也是咨询类公司的最爱。
这些玩意儿，有的可以忽悠大公司，有的可以忽悠小公司，反正谁也别想逃掉。但毒瘤如果能够为我们带来利益，当然也要拥抱。不要那么死板嘛。
当妖风袭来，比起关上窗子，我们要拥抱它，要投其所好!为什么有的人工资高，有的人升的快!有的人成为了大师!要从根本上想想原因。
概念能够升华体系
你知道么?越是职位高的人，越容易喜欢虚无缥缈的东西。拿古代的皇帝来说，有很多期望与神仙相会的，就被方士骗的死去活来。
即使到最后知道被骗了，也只能偷偷的把消息封锁起来。最近看《资治通鉴》，就发现了很多这样的案例。
一来，是他们真的有这种需求;二来，是怕这些事被曝光了丢脸，只能咬牙坚持下去。
地球上没有新鲜事，放到软件行业也一样。当我们把一件东西给神化，赋予它某些超自然的能力，它就能在方士的路上越走越平坦。
如何神化?抓痛点、谈愿景、搞方法论，一般就能够销售成功。
当然，销售成功只是第一步，我们还要避免失败，避免被秋后算账。所以，我们需要把决策者的积极性调动起来，让他认识到自己的不足，羞于承认自己的弱点，我们就算落稳脚步了。
只要决策者上了船，他就会想方设法美化它，争取更多的资源，让更多的人上船。
为什么互联网黑话生命力强劲，就是因为它能忽悠，能够升华你的思想，而不是空洞洞的代码。
我这里举个例子：有一家公司，由于研发的人数有限，但是活儿很多，分散在多个系统之间。
研发部门研究出来的结论是：要聚焦，集中力量到核心系统上。怎么办?不能在 PPT 上干巴巴的写上聚焦两个字吧，那显得多 LOW。
思来想去，突然灵机一动。要不，我们造点名词吧。按照级别，分它个 CVP 系统、IVP 系统、EVP 系统。这样，一下子逼格就上升了不少。
看不懂这些名词?看不懂就对了，因为这是我造的，要的就是看不懂这种效果。
看看下面这张图，我们甚至可以赋予它属性，把系统归类到这三类之中。
重要的是，业务系统的聚焦，摇身一变，成为了 CVP 的重点建设。哈哈，比起一句话就完事的决策，我们这下可以聊很久了。
“教你怎么说话十分钟，等于什么都没说”。这是一种非常重要的能力。
那么，我们就来看一下，这些技术到底是什么?为什么是毒瘤?为什么要拥抱它们。
D 不 D 的 D 的，有啥区别么
所谓领域驱动，就是根据需求设计系统，这句话本来就是废话。有 Demo 代码没?有 Demo 代码没?有 Demo 代码没?有 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 这些概念，与比特币之类的概念，并没有什么区别。这就是信仰的魔力，这就是大师的力量啊!
结语
只有像我这样诚实的人，才会偶尔喷一喷。然后转身，把 DDD 写在了自己的方案上。
是的，我可以写上，也可以讨论，也可以思维碰撞，但我永远不会轻易用它。只有在发广告的时候，我才会把它吹成自己的亲爹。
PS：本文仅代表作者观点，不代表平台观点。分享此文只为抛砖引玉，欢迎大家底部留言讨论对 DDD 的见解!
作者：小姐姐味道
编辑：陶家龙
出处：转载自公众号姐姐味道(ID：xjjdog)，注：本文仅代表作者观点，不代表平台观点。
