阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 小姐姐味道 「小姐姐养的狗」欢迎转载，保留摘要，谢谢！

• 概念能够升华体系
• D不D的D的，有啥区别么
• 尴尬局面
• End

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

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

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

它们就是中台、低代码，以及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这些概念，与比特币之类的概念，并没有什么区别。这就是信仰的魔力，这就是大师的力量啊！

End

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