牛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這些概念，與比特幣之類的概念，并沒有什么區別。這就是信仰的魔力，這就是大師的力量啊！