DDD領(lǐng)域驅(qū)動設計批評文集“軟件方法建模師”不再考查基礎(chǔ)題
《軟件方法》各章合集一、說在前面這兩天在“ Thoughtworks洞見”公眾號上看到一篇付施威的《DDD診所——聚合過大綜合癥》。相對于DDD圈子各種各樣錯誤百出的玄學文章，這篇《DDD診所》已經(jīng)算是想要認真探討問題的難得之作，說得粗俗一點——可以算是翔中的豆芽菜或金針菇了。如果僅僅是自娛自樂的學習心得，只要不自吹“創(chuàng)新”、“棒棒噠”或被人熱捧為“創(chuàng)新”、“棒棒噠”，我是不會去批評的-參見《“以炮換馬”的DDD歪招是否可以作為起步》。但這里作者要去當醫(yī)生治療病人了（雖然不收診金），那就得好好說一說了。其實我要批評的幾點，在之前我寫的《DDD領(lǐng)域驅(qū)動設計批評文集》序列文章中都提過（因此本文我會偷懶，放上大量我寫過的文章的內(nèi)容截圖），這篇文章也不幸一一命中，這并非偶然。從我開始寫《DDD領(lǐng)域驅(qū)動設計批評-合集》序列文章，到現(xiàn)在已經(jīng)有4年了，在這期間：*沒有人針對我寫的文章內(nèi)容做出反駁；*有個別DDD粉絲嫌我氣量狹窄，《潘老師，你的氣度有點小了！》；*有個別DDD圈子人士質(zhì)疑我的動機，《批DDD不批馬保國，說白了就是DDD影響生意了》、《回應張逸老師（一）圈子文化》；*沒有DDD圈子人士當面（包括線下和線上）對我惡語相向，都是很禮貌地叫我“潘老師”；*【我推測】大多數(shù)DDD圈子人士沒有稍為認真地掃一遍我寫的文章；*少數(shù)DDD圈子人士表現(xiàn)出很有誠意和我討論和向我學習建模。我說，如果樂意學習或和我討論，可以先看書和做題，我出了幾百道掃碼自測題，做對大半后，如果有問題可以再討論——理由參見：《軟件方法》分步改進指南《軟件方法》自測題為什么不直接給出答案漫畫版《軟件方法》、奶頭樂和高數(shù)買菜；*但是（往往真正要說的藏在這里）！目前為止，我還沒有發(fā)現(xiàn)DDD圈子有人按照我的建議認真去做——這個我看得出來的。我描述的上述若干現(xiàn)象，看起來有點詭異甚至互相矛盾，對吧？可以看我寫的《小甜甜和牛夫人？》，理解了這個圈子的創(chuàng)新觀和風氣，就不覺得詭異了。（可能有的讀者會說，你自我感覺怎么這么好？大家都很忙，你阿貓阿狗隨便寫點什么，人家憑什么要認真看，認真學習或認真反駁？問題在于，至少在這一點點上，我不是阿貓阿狗啊。畢竟圈子吹捧的這個東西，我還是最早引進的人之一，參見《小甜甜和牛夫人？》）**********下面，我按照《DDD診所》的文章結(jié)構(gòu)依次評點，其中最嚴厲的批評出現(xiàn)在【治療建議】部分。二、【患者主訴】評點《DDD診所》的這部分羅列了系統(tǒng)的一些功能以及存在的問題。（1）羅列功能可以加上（或改成）業(yè)務序列圖。以下例子可供參考。2022年，《DDD診所》作者所在公司Thoughtworks的另一位同事曾來上我的課，并提供了一個“企業(yè)持續(xù)交付流水線平臺”的案例項目在課上剖析，現(xiàn)在又看到《DDD診所》這篇文章里也提到類似項目，不知道兩者之間有沒有關(guān)系。以下幾張圖就是當時我在課上和學員討論后針對“企業(yè)持續(xù)交付流水線平臺”案例畫的第一個迭代的現(xiàn)狀業(yè)務序列圖、改進后業(yè)務序列圖和系統(tǒng)用例圖。

?

圖1 現(xiàn)狀業(yè)務序列圖

?

圖2 改進后的業(yè)務序列圖

圖3 系統(tǒng)用例圖以上圖僅在課上短時間內(nèi)完成，僅供參考。（2）類圖很可能逃避了最難也最有價值的規(guī)則部分接下來，《DDD診所》給出了一張類圖：

圖4 《DDD診所》中的類圖能認認真真畫一張類圖，光是這一點就已經(jīng)壓倒很多DDD文章。很多DDD文章列出兩三個類，甚至有的就一個類，然后就開始往上批量刷**Service、**Repository?！禗DD診所》所給出的類圖中，類的個數(shù)遠遠超越了那些文章，而且我仔細看了類圖，表示法上也基本沒有什么問題。可能存在的問題是內(nèi)容的問題：規(guī)則沒有顯式建模。類圖右側(cè)的“觸發(fā)規(guī)則”、“階段質(zhì)量門禁項”的比較規(guī)則，這些“規(guī)則”不是獨立的，它們隱藏在類以及關(guān)系之中，應該在類圖上顯式表達。很多人經(jīng)常犯的錯誤就是，輕飄飄地用一個類“**規(guī)則”搞定，似乎這樣做之后“**規(guī)則”就會從天上掉下來。這其實是逃避了問題，因為封裝“**規(guī)則”相關(guān)的知識，很可能就是你的系統(tǒng)存在的理由。（如果“**規(guī)則”里面的邏輯已經(jīng)由第三方搞定，那么必定還會有另外一個“**規(guī)則”的邏輯是你的系統(tǒng)存在的理由，錢哪里是那么好掙的？）如果一個類的名稱是以下面這些結(jié)尾：er、or、器、策略、Strategy、Policy、規(guī)則、Rule、算法、Algorithm……一定要警惕，有可能這種類是逃避了真正問題的廢話。關(guān)于這個內(nèi)容，我之前的文章《軟件開發(fā)團隊的膿包》里面的“廢話迷”部分可以參考：

圖5?《軟件開發(fā)團隊的膿包》的“廢話迷”部分截圖我寫的《軟件方法》下冊第8章也可以參考：

圖6 《軟件方法》第8章截圖上面提到的“企業(yè)持續(xù)交付流水線平臺”，我當時在課上畫過一個類圖，也可以作為參考。灰色部分表達了規(guī)則。

圖7 我在課上畫的類圖規(guī)則表達清楚了，剩下的就相對簡單了，無非是在規(guī)則上玩游戲，把結(jié)果記錄下來。不過，我們看到的很多建模者，能力僅能達到“把結(jié)果記錄下來”，很難做到“顯式描述規(guī)則”。而“顯式描述規(guī)則”的缺失，往往會帶來另一個錯誤：事物規(guī)格和事物不分。例如，圖4中，“階段”、“步驟”中的“參數(shù)”指的是什么？是名稱還是值？項目的哪一個階段（步驟）應該有什么樣的參數(shù)？這是一個知識。某個具體項目的某個階段（步驟）什么時間發(fā)生的，具體參數(shù)值是多少？這是另一個知識。這兩個知識變化頻率不一樣，不能用一個概念覆蓋。還有像這個：

圖8 《DDD診所》中的經(jīng)“醫(yī)生”診斷后的類圖圖中這樣一寫“下一個步驟是階段的步驟列表中的下一個”就完了？然后好事就從天上掉下來了？步驟的順序在哪里呢？這可不是在“步驟”中加個“序號”屬性或者在“步驟”上建一個自反關(guān)聯(lián)就能解決的。一個階段有哪些步驟？它們之間的順序如何？這是一個知識。張三的項目當前到了某某階段的某某步驟，這是另一個知識。這兩個知識不分開，必定會導致大量冗余的數(shù)據(jù)（即對象的屬性值）。三、【診斷】評點這一部分描述了使用聚合/組合時要警惕的問題。這個部分的問題主要是造詞，“***綜合癥”之類。另外，“聚合根”就是一個偽創(chuàng)新，這個內(nèi)容我在《DDD話語“聚合”中的偽創(chuàng)新》中已經(jīng)寫過，不是本文批評的重點。四、【治療建議】評點這是本文批評的重點。（1）《DDD診所》引用的文字存在嚴重的翻譯錯誤。為了“治療”，《DDD診所》先摘了一段《領(lǐng)域驅(qū)動設計》中譯本的文字：

圖9 《DDD診所》截圖可以看出，《DDD診所》的作者所摘的文字應該來自人民郵電出版社2016年的譯本。這個譯本翻譯得很糟糕！《DDD診所》所摘的內(nèi)容，原文并不是在一起的，而是分離的兩段話。我在文章《猴子掰玉米？比較不同版《領(lǐng)域驅(qū)動設計》說“不變式”和“聚合”》中針對第二段譯文做了評價。

圖10?《猴子掰玉米？比較不同版《領(lǐng)域驅(qū)動設計》說“不變式”和“聚合”》截圖圖10中的重點是：不變式是類的不變式，是類所封裝的邏輯，而不是說有個孤立的“不變式”，然后幾個類去滿足它。而這一點，《DDD診所》的作者應該不了解，例如，他在文章里說“訂單與訂單行之間存在固定規(guī)則”：

圖11 《DDD診所》截圖有趣的是，《DDD診所》的作者還引了維基百科作為佐證：

圖12 《DDD診所》所引用的維基百科問題是，我們討論的是面向?qū)ο笳Z境下的不變式（部分歷史可參見《“**領(lǐng)域驅(qū)動設計”的這個不變式是不是多余》），面向?qū)ο笳Z境下，所有的邏輯都封裝在類里面?！禗DD診所》里用的方法應該是（或者自以為是）面向?qū)ο蠓椒ò?？如果不是面向?qū)ο?，而是作者剛?chuàng)新的“領(lǐng)域驅(qū)動設計大模型人工智能數(shù)智化敏捷方法”，那以下文字就當我沒說。不變式所表達的本來就是一段規(guī)則，你愛怎么組織都可以。面向?qū)ο蟮慕M織，就是把這些規(guī)則按類組織，從而把邏輯封裝在類中。例如，越南某公司有這么一些規(guī)則：員工年齡不得超過性別的年齡上限，例如男性45，女性50。還有，部門中男員工人數(shù)不得超過女員工人數(shù)的2倍?？梢苑譃閮蓚€類的不變式：

圖13 “員工”的不變式和“部門”的不變式可以看到，不變式是放在類上面的，并不是像圖8、圖16和圖18一樣，放在類關(guān)系上。我們還可以觀察到，“員工”的直接或間接屬性有：年齡、員工性別.年齡上限、員工性別.名稱。要是這些屬性的值的組合沒有任何約束（例如年齡46，性別男），那么系統(tǒng)的復雜度會大大降低——可惜，現(xiàn)實中不是這樣（這正是圖10中Bjarne Stroustrup所強調(diào)的）?！皢T工”的不變式正是這些屬性之間的約束的一個表達式——并不是像圖8那樣意淫式地隨便寫句話；（不變式如何表達，參見《不變式有標準或者語法嗎》）同樣，“部門”的直接和間接屬性，除了“員工”集合之外，還包括上面列出的“員工”的直接或間接屬性，而“部門”的不變式正是這些屬性之間的約束的一個表達式——并不是像圖8那樣意淫式地隨便寫句話。那可不可以把“員工”和“部門”的關(guān)聯(lián)方向倒過來？可以的。這時，原來加在“員工”上的不變式應該不用修改，但原來加在“部門”上的不變式就要挪到員工上（因為“部門”訪問不到剛才那些屬性了），而且表達式也要修改——肯定能表達，無非是集合運算，區(qū)別在于更直接還是更彎彎繞而已。從這一點也可以看出，到底是“員工”知道“部門”合適，還是“部門”知道“員工”更合適？不變式可以作為參考依據(jù)之一。

要提醒的是，不變式僅僅是表達邏輯的選擇之一，而且也僅能表達部分邏輯。

DDD圈子為什么獨獨吹捧這個呢？哦，因為《領(lǐng)域驅(qū)動設計》提到了它，更關(guān)鍵的是，這個圈子是一個封閉的互吹互捧的圈子。

（2）問題更大的是，《DDD診所》的作者對譯文的糟糕沒有敏感性。最簡單的一點，Invariant譯為“固定規(guī)則”的，【我見過的】是獨此一家！列舉幾本有一定水平的書（說的是原著），有譯作“不變式”的：

圖14 Meilir Page-Jones《UML面向?qū)ο笤O計基礎(chǔ)》（人民郵電出版社）截圖有譯作“不變量”的：

圖15 Ian Graham《面向?qū)ο蠓椒ㄔ砼c實踐（原書第3版）》（機械工業(yè)出版社）截圖以上所列，都不是UMLChina譯，以免被認為故意挑選。《DDD診所》的作者居然不覺得有違和感，是因為只看過《領(lǐng)域驅(qū)動設計》的這個譯本，而沒有看過其他書？如果《DDD診所》的作者手上資源有限，例如，沒有別的譯本，沒有英文原文，沒看過其他書……那應該想辦法去豐富自己的資源，等學習好了再給人看病。當然，如果創(chuàng)新觀和我在《小甜甜和牛夫人？》中評論的創(chuàng)新觀一樣，那我就不再對此說什么了。（3）問題最大的，《DDD診所》的作者缺乏對“廢話”的基本敏感。不了解或誤解（1）中我說的不變式的知識，這個好說，花時間學習就是。下面這個才是我認為最嚴重的：

圖16 《DDD診所》截圖《DDD診所》的作者把“A更新的時候，會不會引起B(yǎng)的某個屬性的更新”，“如果兩個實體暫時不一致，是否會導致難以承受的業(yè)務后果”、“訂單的總價等于訂單行的總價之和”看作不變式要表達的內(nèi)容?！@是不變式嗎？這是冗余吧？像圖中“訂單的總價等于訂單行的總價之和”，如果這個公式被嚴格遵守，那么“訂單”類的“總價”屬性在邏輯上就是冗余的，應該刪掉。既然“訂單”的“總價”屬性沒了，圖16上所標的不變式也就不存在了。那怎樣才是“訂單”需要表達的不變式呢，我舉下面的例子供參考：

圖17 合理的不變式“訂單”類中不變式的意思是：任何一個訂單對象，其訂單項集合中不存在這樣的訂單項，本訂單的配送地址所屬區(qū)域就在該訂單項所購商品的禁售區(qū)域內(nèi)。例如，某款“iPhone**”不能賣往長三角地區(qū)，如果訂單的配送地址是“南京市****”，那么訂單里面是不能存在購買“iPhone**”的訂單項的。注意，我給出的圖13、圖17等類圖，上面的信息沒有冗余。**********面對冗余，建模者毫無察覺，反而甘之如飴，這說明建模者缺乏基本的建模訓練，這已經(jīng)和面向?qū)ο蠡虿蛔兪經(jīng)]關(guān)系，即使辯解說“我用的不是面向?qū)ο?，用的是領(lǐng)域驅(qū)動設計大模型人工智能數(shù)智化敏捷方法”也一樣的。我在另一篇文章《“**領(lǐng)域驅(qū)動設計”的這個不變式是不是多余》中也批評了類似的“不變式”廢話：

圖18?《“**領(lǐng)域驅(qū)動設計”的這個不變式是不是多余》截圖

難怪，我一直“贊揚”很多DDD偽創(chuàng)新：投資少、見效快、產(chǎn)量高、門檻低、儀式感十足，它們確實迎合了某些開發(fā)人員的需要。

很可能有人會以“性能”為理由為自己的能力缺乏辯護。是的，如果在實現(xiàn)時確實由于需要頻繁計算訂單總價，導致出現(xiàn)不可調(diào)和的性能問題，可以添加上冗余屬性（用數(shù)據(jù)庫語言就是冗余字段）“總價”，甚至添加冗余類（用數(shù)據(jù)庫語言就是冗余表），但這屬于通過添加冗余來緩解性能問題的實現(xiàn)套路，和具體的領(lǐng)域知識無關(guān)。關(guān)于“性能”這塊遮羞布，可以參考《軟件方法》中的內(nèi)容。

圖19 《軟件方法》“性能”截圖1

圖20 《軟件方法》“性能”截圖2