概念能夠升華體系

D不D的D的，有啥區(qū)別么

尷尬局面

End

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

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

它們就是中臺、低代碼，以及DDD。這三個不同領(lǐng)域中的技術(shù)，肩負(fù)著同樣的責(zé)任，那就是往死里忽悠。這三個詞，很偉大，它們有一個共同點，都是很容易說服非技術(shù)但能決策的人員，然后向下鋪開，非常具有營銷型，是職業(yè)經(jīng)理人和CTO的最愛。也是咨詢類公司的最愛。

這些玩意兒，有的可以忽悠大公司，有的可以忽悠小公司，反正誰也別想逃掉。

但毒瘤如果能夠為我們帶來利益，當(dāng)然也要擁抱。不要那么死板嘛。

當(dāng)妖風(fēng)襲來，比起關(guān)上窗子，我們要擁抱它，要投其所好！為什么有的人工資高，有的人升的快！有的人成為了大師！要從根本上想想原因。

概念能夠升華體系

你知道么？越是職位高的人，越容易喜歡虛無縹緲的東西。拿古代的皇帝來說，有很多期望與神仙相會的，就被方士騙的死去活來。即使到最后知道被騙了，也只能偷偷的把消息封鎖起來。最近看《資治通鑒》，就發(fā)現(xiàn)了很多這樣的案例。

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

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

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

當(dāng)然，銷售成功只是第一步，我們還要避免失敗，避免被秋后算賬。所以，我們需要把決策者的積極性調(diào)動起來，讓他認(rèn)識到自己的不足，羞于承認(rèn)自己的弱點，我們就算落穩(wěn)腳步了。只要決策者上了船，他就會想方設(shè)法美化它，爭取更多的資源，讓更多的人上船。

為什么互聯(lián)網(wǎng)黑話生命力強勁，就是因為它能忽悠，能夠升華你的思想，而不是空洞洞的代碼。

我這里舉個例子。

有一家公司，由于研發(fā)的人數(shù)有限，但是活兒很多，分散在多個系統(tǒng)之間。研發(fā)部門研究出來的結(jié)論是：要聚焦，集中力量到核心系統(tǒng)上。怎么辦？不能在PPT上干巴巴的寫上聚焦兩個字吧，那顯得多LOW。

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

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

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

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

“教你怎么說話十分鐘，等于什么都沒說”。這是一種非常重要的能力。

那么，我們就來看一下，這些技術(shù)到底是什么？為什么是毒瘤？為什么要擁抱它們。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

D不D的D的，有啥區(qū)別么

所謂領(lǐng)域驅(qū)動，就是根據(jù)需求設(shè)計系統(tǒng)，這句話本來就是廢話。

有Demo代碼沒？

有Demo代碼沒？

有Demo代碼沒？

有Demo代碼沒？

所有的文章下面，都充滿了這樣的發(fā)問。如果說DDD層只是戰(zhàn)略上有用，那它就不應(yīng)該進(jìn)入程序員視野，它應(yīng)該是需求分析師的玩具。DDD應(yīng)該學(xué)學(xué)TOGAF、COBIT、CGEIT之類的培訓(xùn)，把眼光放在戰(zhàn)略布局上，不要老是想著革程序員的命，搞什么戰(zhàn)術(shù)。

你要是專心搞搞業(yè)務(wù)培訓(xùn)證書，你賺你的錢我做我的架構(gòu)設(shè)計，咱們井水不犯河水。但你要把觸角伸到我的領(lǐng)域，就會招來像我這樣的噴子。

DDD正確的打開方式，就是擁抱它的戰(zhàn)略階段，完全扔掉它的戰(zhàn)術(shù)階段。這樣做，你會活的很舒坦。原諒我使用“限界上下文”這樣的名詞來解釋一下：你只要把我的服務(wù)邊界劃分清楚了，你管我后面是怎么實現(xiàn)呢，設(shè)計模式和架構(gòu)模式，我的工具箱多的很，并不缺CQRS、事件溯源這樣的名詞。

DDD的概念最早來源于2004年，這么多年沒火，沒有標(biāo)準(zhǔn)落地，不是沒有原因的。最近幾年，有些人發(fā)現(xiàn)了技術(shù)名詞的貧瘠，重新?lián)炱鹆怂Ｍ芾^續(xù)為KPI效力。

我曾癡迷DDD，被它的美好愿景折磨的興奮無比。買了網(wǎng)課，買了書籍，到最后發(fā)現(xiàn)它在浪費我的時間。我恨它。恕我直言，一個難度高，落地難的技術(shù)方案，根本沒有資格讓人分割精力去了解它。

不好意思，沒有路轉(zhuǎn)粉。

首先，搞DDD的，都是些卷中卷公司，它不像微服務(wù)技術(shù)一樣，能夠找到大量落地的方案。實際上，你幾乎找不到任何有價值的參考示例，更別說這些示例之間還相互打臉。它就像是圣經(jīng)一樣，給你說什么是對的，但怎么做，全靠你悟。

為什么你干不了DDD，你的團隊干不了DDD？DDD給出了三個主要原因。

對團隊的要求較高。畫外音，你做不好是你的團隊不行

只有復(fù)雜的業(yè)務(wù)使用DDD才能見效。那什么是復(fù)雜呢？并沒有定論。話外音，你覺得不好用，那是你的業(yè)務(wù)不夠復(fù)雜

雖然你用不了DDD，但其中的思想，還是值得借鑒和思考的。畫外音，我是萬金油，不會讓你白學(xué)

沒有人會承認(rèn)自己的團隊不行，沒有團隊會承認(rèn)自己的業(yè)務(wù)簡單，沒人能忍受自己的投入就真的肉包子打狗了。DDD通過幾個讓你不能打臉的理由，瞬間將你綁在了一起。

2020年，花了整整三個月時間，有幸拜讀了《實現(xiàn)領(lǐng)域驅(qū)動設(shè)計》這本書，對其深厚的文字運用水平驚嘆拜服。以后，即使一個簡單的CRUD項目，我也知道文檔應(yīng)該怎么寫了，這本書就是非常好的案例。

你搜一下DDD的文章，不論什么文章，都有一個特點，那就是不能好好的說人話。所有的應(yīng)用代碼，都是一堆無法說服人的垃圾代碼。因為開發(fā)者和正常的寫法一比較，發(fā)現(xiàn)自己在找罪受，那為什么要用它呢？

就拿吹的很牛b的六邊形架構(gòu)來說吧。

六邊形架構(gòu)，因為長得像蜂窩，看起來就很靠近綠色的自然界，很高大上。說實話，我到現(xiàn)在都沒弄明白六邊形架構(gòu)，八邊形架構(gòu)（沒這種東西），三角形架構(gòu)（沒這種東西）之間，到底有何區(qū)別，這群名詞狂魔為啥選擇了6這個數(shù)字。

您就直說，復(fù)雜的業(yè)務(wù)邏輯，不應(yīng)該過多的關(guān)注技術(shù)等基礎(chǔ)設(shè)施、但要預(yù)留接口就行了，非要整的這么玄乎，一條條蚯蚓一樣的線從那腐爛的六邊形上輻射出來。覺得很美么？或許老板真這么覺得，因為它像彩虹一樣的名詞輪，確實能唬住一群蹉B。

不要說ServiceMesh的數(shù)據(jù)平面和控制平面分割，是靠DDD指導(dǎo)的哦，雖然它概念上靠的上。

下圖是google搜索Hexagonal Architecture出現(xiàn)的一張圖。

哎吆，六邊形呢？這圖怎么整了個10邊形？那還是六邊形架構(gòu)么？您忽悠小孩子呢？當(dāng)我不識數(shù)？什么，你又把它叫做洋蔥頭架構(gòu)，它們不是一個東西？這樣的誤解在DDD中比比皆是，我也不想解釋，因為它們都是短話長說。這說明了它是一門全面的忽悠方法論，是靠堆概念和黑話起家的，宣傳者也不合格。

整個DDD這一套概念，價值觀就有問題。或者說作者的本意或許是好的，面向的是復(fù)雜業(yè)務(wù)。結(jié)果讓這群宣傳者和培訓(xùn)一搗鼓，就成了解決問題的必要手段。

但是不好意思，您連起碼的順暢交流都沒整好，沒資格教別人做架構(gòu)。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://gitee.com/zhijiantianya/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

尷尬局面

讓人覺得尷尬的是，真正需要DDD的人，并不認(rèn)同它；不需要DDD的人，被強迫認(rèn)同它。

DDD最大的價值是梳理業(yè)務(wù)性需求，將不同的業(yè)務(wù)領(lǐng)域劃分出來，并形成領(lǐng)域之間的接口交互。說個實話，我見過很多咨詢公司的大佬，他們對這種想要通吃的方法論嗤之以鼻，更傾向于使用TOGAF之類老牌的業(yè)務(wù)梳理方法。但條條道路通羅馬，最終的領(lǐng)域劃分還是能夠達(dá)成一致。

這些梳理的過程，大部分是業(yè)務(wù)專家，以及系統(tǒng)架構(gòu)師的范疇。他們的工作成果，將作為輸入輸出到技術(shù)團隊實現(xiàn)。他們需要DDD，但他們并不用。

相比較而言，DDD的戰(zhàn)術(shù)階段，毫無價值而言。比如，把數(shù)據(jù)匯總到寬表或者大數(shù)據(jù)中心，形成數(shù)據(jù)“中臺”提供交易域、管理域、查詢域的分離，我并不需要知道什么CQRS的概念，也能工作的很好。至于實體充血不充血，我本來就是微服務(wù)了，業(yè)務(wù)粒度本來就很小了，要怎么寫是我的自由，改造也是我自己的成本，我并不需要按照你那一套來。談業(yè)務(wù)和技術(shù)的溝通？不好意思，不能溝通而去做業(yè)務(wù)的團隊，我還沒見過。

工程師被決策層強迫使用DDD戰(zhàn)術(shù)書寫業(yè)務(wù)，結(jié)果代碼更亂，更改更加頻繁。但是DDD說，不好意思，不是我的錯，是你團隊不行。

道理是這個道理，但在現(xiàn)實中，還是有人吹噓、甚至使用這個東西去改造代碼。《微服務(wù)架構(gòu)模式》這本書，甚至有事件溯源和CQRS兩個章節(jié)，去專門講解DDD的一些落地的內(nèi)容。這叫做大師毒害了大師，當(dāng)然也叫做相互扶持。

恕我直言，如果你信了這些鬼話，大概率會把項目帶入死亡。盡信書不如無書，架構(gòu)是一種權(quán)衡，并沒有通吃的指導(dǎo)思路。你可以參考，可以思考，但就是不能照搬，因為每個公司的技術(shù)前提都不一樣。

話雖如此，但當(dāng)一些概念被吹噓起來的時候，你不去擁抱它，反而會產(chǎn)生問題。軟件行業(yè)有兩個難題，一個是怎么把復(fù)雜的事情簡單的匯報，另外一個就是把簡單的東西搞復(fù)雜。對于前者，主要是描述你構(gòu)想的可行性。而對于后者，主要的目的就是讓人覺得很高大上，很主流，越晦澀越好。前者腳踏實地，后者口吐蓮花。

而后者的功效，顯然要比前一種有效得多。讓人聽上去感覺很牛x，但是聽不懂，可以獲得掌聲，也可以體驗高高在上的感覺。沒人會承認(rèn)自己的智商不在線，你需要激起這些人的活力。只要有人認(rèn)同，就可以產(chǎn)生利益。

有些概念，有些人，并不是神，但利益共同體，需要他成為神。這玩意也有信徒，你信么？但軟件設(shè)計的工具，難道不是合適就用，不合適就扔么？為什么會成為信徒？僅僅是因為上船了而已。

朋友們，在一定程度上，DDD這些概念，與比特幣之類的概念，并沒有什么區(qū)別。這就是信仰的魔力，這就是大師的力量啊！

End

只有像我這樣誠實的人，才會偶爾噴一噴。然后轉(zhuǎn)身，把DDD寫在了自己的方案上。是的，我可以寫上，也可以討論，也可以思維碰撞，但我永遠(yuǎn)不會輕易用它。

審核編輯 ：李倩