[[431042]]

圖片來自 包圖網

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

它們就是中臺、低代碼，以及 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 這些概念，與比特幣之類的概念，并沒有什么區別。這就是信仰的魔力，這就是大師的力量啊!

結語

只有像我這樣誠實的人，才會偶爾噴一噴。然后轉身，把 DDD 寫在了自己的方案上。

是的，我可以寫上，也可以討論，也可以思維碰撞，但我永遠不會輕易用它。只有在發廣告的時候，我才會把它吹成自己的親爹。

PS：本文僅代表作者觀點，不代表平臺觀點。分享此文只為拋磚引玉，歡迎大家底部留言討論對 DDD 的見解!

作者：小姐姐味道

編輯：陶家龍

出處：轉載自公眾號姐姐味道(ID：xjjdog)，注：本文僅代表作者觀點，不代表平臺觀點。