ddd流行不起來（但我永遠不會輕易使用它）

2023-08-01 17:59:48

牛 B 的人物，早已經厭倦了中英文混雜，他們更進一步，使用中英文縮寫，對普通人進行降維打擊。更厲害的，造就新的名詞，併科普出去。

圖片來自 包圖網

有幾項技術，我從心底裡鄙視和厭惡，但每次在技術方案中，都默默的把它們加進去，而且給足了它們分量。因為它們對於方案的成功與否，起著重要的概念性指導作用。

它們就是中臺、低代碼，以及 DDD。這三個不同領域中的技術，肩負著同樣的責任，那就是往死裡忽悠。

這三個詞，很偉大，它們有一個共同點，都是很容易說服非技術但能決策的人員，然後向下鋪開，非常具有營銷型，是職業經理人和 CTO 的最愛。也是諮詢類公司的最愛。

這些玩意兒，有的可以忽悠大公司，有的可以忽悠小公司，反正誰也別想逃掉。但毒瘤如果能夠為我們帶來利益，當然也要擁抱。不要那麼死板嘛。

當妖風襲來，比起關上窗子，我們要擁抱它，要投其所好!為什麼有的人工資高，有的人升的快!有的人成為了大師!要從根本上想想原因。

你知道麼?越是職位高的人，越容易喜歡虛無縹緲的東西。拿古代的皇帝來說，有很多期望與神仙相會的，就被方士騙的死去活來。

即使到最後知道被騙了，也只能偷偷的把消息封鎖起來。最近看《資治通鑑》，就發現了很多這樣的案例。

一來，是他們真的有這種需求;二來，是怕這些事被曝光了丟臉，只能咬牙堅持下去。

地球上沒有新鮮事，放到軟體行業也一樣。當我們把一件東西給神化，賦予它某些超自然的能力，它就能在方士的路上越走越平坦。

如何神化?抓痛點、談願景、搞方法論，一般就能夠銷售成功。

當然，銷售成功只是第一步，我們還要避免失敗，避免被秋後算帳。所以，我們需要把決策者的積極性調動起來，讓他認識到自己的不足，羞於承認自己的弱點，我們就算落穩腳步了。

只要決策者上了船，他就會想方設法美化它，爭取更多的資源，讓更多的人上船。

為什麼網際網路黑話生命力強勁，就是因為它能忽悠，能夠升華你的思想，而不是空洞洞的代碼。

我這裡舉個例子：有一家公司，由於研發的人數有限，但是活兒很多，分散在多個系統之間。

研發部門研究出來的結論是：要聚焦，集中力量到核心系統上。怎麼辦?不能在 PPT 上乾巴巴的寫上聚焦兩個字吧，那顯得多 LOW。

思來想去，突然靈機一動。要不，我們造點名詞吧。按照級別，分它個 CVP 系統、IVP 系統、EVP 系統。這樣，一下子逼格就上升了不少。

看不懂這些名詞?看不懂就對了，因為這是我造的，要的就是看不懂這種效果。

看看下面這張圖，我們甚至可以賦予它屬性，把系統歸類到這三類之中。

重要的是，業務系統的聚焦，搖身一變，成為了 CVP 的重點建設。哈哈，比起一句話就完事的決策，我們這下可以聊很久了。

「教你怎麼說話十分鐘，等於什麼都沒說」。這是一種非常重要的能力。

那麼，我們就來看一下，這些技術到底是什麼?為什麼是毒瘤?為什麼要擁抱它們。

所謂領域驅動，就是根據需求設計系統，這句話本來就是廢話。有 Demo 代碼沒?有 Demo 代碼沒?有 Demo 代碼沒?有 Demo 代碼沒?

所有的文章下面，都充滿了這樣的發問。如果說 DDD 層只是戰略上有用，那它就不應該進入程式設計師視野，它應該是需求分析師的玩具。

DDD 應該學學 TOGAF、COBIT、CGEIT 之類的培訓，把眼光放在戰略布局上，不要老是想著革程式設計師的命，搞什麼戰術。

你要是專心搞搞業務培訓證書，你賺你的錢我做我的架構設計，咱們井水不犯河水。但你要把觸角伸到我的領域，就會招來像我這樣的噴子。

DDD 正確的打開方式，就是擁抱它的戰略階段，完全扔掉它的戰術階段。這樣做，你會活的很舒坦。

原諒我使用「限界上下文」這樣的名詞來解釋一下：你只要把我的服務邊界劃分清楚了，你管我後面是怎麼實現呢，設計模式和架構模式，我的工具箱多的很，並不缺 CQRS、事件溯源這樣的名詞。

DDD 的概念最早來源於 2004 年，這麼多年沒火，沒有標準落地，不是沒有原因的。

最近幾年，有些人發現了技術名詞的貧瘠，重新撿起了它，希望它能繼續為 KPI 效力。

我曾痴迷 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)，註：本文僅代表作者觀點，不代表平臺觀點。