牛 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 写在了本人的计划上。是的，我能够写上，也能够探讨，也能够思维碰撞，但我永远不会轻易用它。