擁抱毒瘤 DDD！

原創：小姐姐味道（微信公衆號 ID：xjjdog），歡迎分享，轉載請保留出處。

牛 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 寫在了自己的方案上。是的，我可以寫上，也可以討論，也可以思維碰撞，但我永遠不會輕易用它。

只有在發廣告的時候，我纔會把它吹成自己的親爹。

作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公衆號。聚焦基礎架構和 Linux。十年架構，日百億流量，與你探討高併發世界，給你不一樣的味道。我的個人微信 xjjdog0，歡迎添加好友，進一步交流。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/AhklSNwD1UzHv0hCGNMcVg