真正開始 DDD 旅程前，我想讓您看到經(jīng)過 DDD 設(shè)計(jì)之后的代碼長啥樣。我想，這是所有本著“talking is easy, show me your code”理念的程序員都比較在乎的觀念。

為此，我特別將“群買菜”生鮮電商系統(tǒng)服務(wù)端代碼新舊代碼結(jié)構(gòu)都顯示出來，讓您看看原來的舊代碼——也就是“事務(wù)腳本式”代碼長啥樣(應(yīng)該是目前大部分 java 程序員寫代碼的樣子)，再讓您看看 DDD 改造設(shè)計(jì)后的新代碼長什么樣子。然后再通過分析，說清楚為什么傳統(tǒng)的“事務(wù)腳本”代碼不是對真實(shí)世界的“同構(gòu)映射”，而 DDD 代碼的“同構(gòu)映射”在哪。

需要提醒您的是：從今天這個專題開始，可能需要你多花點(diǎn)時間、深入地閱讀我寫的代碼、和文字的每一句話，反復(fù)對照著看，甚至來回反復(fù)多看幾遍，才能真的去理解這些文字了。

1.舊代碼：事務(wù)腳本式(貧血模型)代碼

我們先來看舊代碼的目錄結(jié)構(gòu)截圖。注意看下面的 1、2、3、4 標(biāo)注位置(解釋下，我這里用的是 spring-boot 開發(fā)框架，MyBatisPlus 數(shù)據(jù)持久框架、MySql5.6 數(shù)據(jù)庫)：

您注意到這里標(biāo)注的 1、2、3、4 代碼位置了嗎?是不是代碼結(jié)構(gòu)很像大部分 spring-boot 應(yīng)用框架下代碼結(jié)構(gòu)?為了避免您可能不太了解這種代碼結(jié)構(gòu)，我還是簡單解釋下。

標(biāo)號 1 位置：這里放的是 Controller(控制器)層代碼，也就是所有前端訪問的接口都在這里實(shí)現(xiàn)。按照 MVC 的分層原則，一般來說，這里只會放一些客戶端輸入?yún)?shù)的解析、以及對 service 層(見下文)的業(yè)務(wù)方法調(diào)用。一般來說，這里的代碼都長成下面這樣：

標(biāo)號 2 位置：這里放的是 entity(數(shù)據(jù) bean)層代碼，其實(shí)都是 POJO 代碼，所有類都一一對應(yīng)到數(shù)據(jù)庫表。一般來說，這里的代碼都長成這樣：

標(biāo)號 3 位置：mapper 層，對于 mybatis 持久層框架來說，mapper 和 entity 共同實(shí)現(xiàn)了 ORM(對象模型到關(guān)系模型的映射)。一般來說，這里的代碼長成這樣(這里 CustomerMapper 類只是定義了 entity 類 Customer 的映射關(guān)系，以及自定義的數(shù)據(jù)操作方法)：

以及這樣(在 MP 中，只有需要實(shí)現(xiàn)自定義的 SQL 操作方法，才需要這個 CustomerMapper.xml 文件)：

標(biāo)號 4 位置：Service(服務(wù))層，這里是所有業(yè)務(wù)邏輯實(shí)現(xiàn)的核心代碼處，幾乎所有的業(yè)務(wù)邏輯都是在這里實(shí)現(xiàn)的。一般來說，這里會有 interface+implementation 組合的實(shí)現(xiàn)方式。比如：OrderService 和 OrderServiceImpl，分別長下面這樣：

OrderService 接口類:

OrderServiceImpl 實(shí)現(xiàn)類;

從上面的代碼中 ，我們可以很明顯地看出如下幾點(diǎn)：

• Controller/entity/mapper 基本上都是利用框架的 annonation(注解)和公共工具類代碼(如 json 解析等)實(shí)現(xiàn)的很少的代碼;
• 顯然，大部分業(yè)務(wù)邏輯都是在 Service 層的實(shí)現(xiàn)類里面實(shí)現(xiàn)的;
• Service 層實(shí)現(xiàn)類代碼的邏輯寫的很長，且完全是“平鋪直述”的。我這里展示的 OrderSeriveImple 的 create 方法——創(chuàng)建訂單，就寫了 135 行。從我的代碼截圖中的注釋可以看出來，我是想好了一步一步要怎么對數(shù)據(jù)庫進(jìn)行 CRUD，先填寫好注釋，然后寫代碼的。這種代碼，說白了就是“CRUD+計(jì)算邏輯”組合的代碼;
• 事實(shí)上，這種“平鋪直述”式的代碼，是很容易被程序理解的，寫起來也很容易，基本上不用“殺死”太多腦細(xì)胞，所以團(tuán)隊(duì)很容易就開始實(shí)施項(xiàng)目工程，隨便找一個具有基本 java 編程經(jīng)驗(yàn)(一般一年以上經(jīng)驗(yàn)即可)就能夠開始著手業(yè)務(wù)代碼的開發(fā);
• 這種代碼，我們就叫做”事務(wù)腳本式”代碼，或者說叫“貧血模型”代碼。

之所以叫“事務(wù)腳本”，我個人的理解：本質(zhì)上跟 20 年前寫數(shù)據(jù)庫存儲過程代碼沒有本質(zhì)區(qū)別(只是換了個語言書寫、運(yùn)行代碼的位置從數(shù)據(jù)庫服務(wù)器內(nèi)部提到了應(yīng)用服務(wù)器);

又之所以叫“貧血模型”代碼，是因?yàn)?entity 層的那些 POJO 對象如 Order 等，沒有任何業(yè)務(wù)行為的封裝(比如：Order 類應(yīng)該自己生成自己的訂單號、提貨號等)，只有屬性而沒有行為的對象，就是“貧血”對象，基于“貧血”對象實(shí)現(xiàn)的業(yè)務(wù)邏輯代碼，就叫“貧血模型”代碼。

根據(jù)這里的代碼分析，我們是不是能夠發(fā)現(xiàn)一個關(guān)鍵問題：這里的 Controller/entity/mapper/service，事實(shí)上和真實(shí)世界的業(yè)務(wù)之間關(guān)系，是沒有任何映射的——也就是說：“代碼世界”和“真實(shí)世界”是異構(gòu)的。具體來說，我們可以分以下幾點(diǎn)來看。

首先，從業(yè)務(wù)模塊劃分這個“最粗”的粒度來說，我們其實(shí)是可以簡單的、憑直覺進(jìn)行模塊劃分的，不用全部業(yè)務(wù)模塊放在一個工程項(xiàng)目中，是可以按照業(yè)務(wù)模塊(比如：店鋪管理、訂單管理、商品管理等)進(jìn)行項(xiàng)目目錄劃分、也就是項(xiàng)目團(tuán)隊(duì)分組的。

事實(shí)上，目前市面上的大多數(shù)軟件公司，就是根據(jù)業(yè)務(wù)經(jīng)驗(yàn)或直覺簡單粗暴的將項(xiàng)目劃分了多個團(tuán)隊(duì)在進(jìn)行開發(fā)。但這種劃分方式，雖然也可以七七八八準(zhǔn)確——但我們需要意識到的是，這樣簡單粗暴的憑經(jīng)驗(yàn)直覺的劃分，跟 DDD 方法論做的設(shè)計(jì)劃分相比(劃分到限界上下文這個粒度的設(shè)計(jì)，在 DDD 中叫做“戰(zhàn)略設(shè)計(jì)”)，至少有 3 個不足：

• 軟件代碼如何劃分是嚴(yán)格的“工程性問題”，而所有工程性問題，往往會“差之毫厘謬以千里”!這種經(jīng)驗(yàn)直覺的劃分，很可能會遺漏掉一些很重要的“限界上下文”識別。而正因?yàn)檫@些重要的“限界上下文”的遺漏，導(dǎo)致了一些模糊地帶，發(fā)現(xiàn)要么是沒必要的模塊間耦合、要么是沒必要的重復(fù)。
• DDD“限界上下文”的識別，不但要區(qū)分出到底要劃分為幾個模塊(其實(shí)“模塊”是個很模糊的詞，可以用來劃分微服務(wù)、也可以用來劃分代碼目錄結(jié)構(gòu)，視需要而定)，還需要識別這些“限界上下文”之間的協(xié)作關(guān)系和邊界。而這些協(xié)作關(guān)系，才真正“清晰準(zhǔn)確、代碼行級”定義了哪些代碼歸屬模塊 A、哪些代碼歸屬模塊 B——也就是邊界，以及這些模塊是通過 RPC 或本地調(diào)用關(guān)系在協(xié)作、還是異步消息事件在協(xié)作、甚至直接就沒有協(xié)作。
• 一般來說，DDD 的“限界上下文”需要對應(yīng)到業(yè)務(wù)子領(lǐng)域，而業(yè)務(wù)子領(lǐng)域的重要程度將決定限界上下文的重要程度。業(yè)務(wù)子領(lǐng)域針對某個具體的軟件系統(tǒng)來說，是可以從業(yè)務(wù)角度判斷出哪些必須建設(shè)為軟件的核心競爭力、哪些則可以作為次要模塊甚至通過外包來實(shí)現(xiàn)。這些對“限界上下文”模塊的不同“重要程度”定義，將會促使項(xiàng)目管理層從效率的角度采用不同的技術(shù)棧。比如：目前市面上不同的程序員薪資水平是不同的、招聘難度是不同的;不同技術(shù)棧的成熟程度、可適用的編程特性是不同的(比如：java 比較成熟適合企業(yè)級應(yīng)用開發(fā)，而 python 適合數(shù)據(jù)處理類開發(fā)，node.js 適合跟第三方互聯(lián)網(wǎng)系統(tǒng)連接等)。

其次，到模塊內(nèi)部，其代碼的層次結(jié)構(gòu)劃分，如果按照 mvc 思想，最后還是又回到了類似 controller/entity/mapper/service 這樣的劃分方式。而這種劃分方式，又和“真實(shí)世界”有什么同構(gòu)映射關(guān)系呢?可以說，沒有!

所以，最終我們還是可以得出結(jié)論：這種傳統(tǒng)的代碼架構(gòu)，是沒有考慮和真實(shí)世界的“同構(gòu)映射”的。而這種對“同構(gòu)映射”的缺失，才是導(dǎo)致我們出現(xiàn)“真實(shí)業(yè)務(wù)其實(shí)沒多大變化、但某個需求卻為什么引起軟件代碼翻天覆地的變化呢?”這樣疑惑的根本原因——DDD 方法論，就是用來解決這個問題的!

2.新代碼：DDD 設(shè)計(jì)代碼(充血模型)

我們再來看看使用 DDD 設(shè)計(jì)后，新的代碼結(jié)構(gòu)長什么樣。下面是新代碼的結(jié)構(gòu)截圖(同樣注意下面的 1~8 標(biāo)號)：

對上面的代碼標(biāo)號位置，我來逐個解釋如下(需要說明的是：這里目錄排序是 IDEA 開發(fā)工具自動按字母順序排序，不是代碼設(shè)計(jì)先后順序)：

標(biāo)號 1 位置：這里放的是邊緣層(edge)代碼。由于“群買菜”小程序前端界面已經(jīng)開發(fā)完成，并且這是一個前后端分離項(xiàng)目，前端代碼我并沒有打算修改，所以這里就多了個“界面適配”的代碼工作。一般來說，這種代碼就叫“邊緣層”。邊緣層放的代碼，都是類似這種為了前端界面適配、第三方系統(tǒng)接口適配之類的代碼。這種代碼，也可以叫做“為前端提供的后端”(Backend for Frontend, BFF)。理論上，這種 BFF 層的代碼，可以由前端團(tuán)隊(duì)開發(fā)的，我可以選擇技術(shù)棧是 Node.js，使用 js 或 ts 語言進(jìn)行開發(fā)。

標(biāo)號 2 位置：這里顯示的是“基礎(chǔ)層”(foudation)。在 DDD 的系統(tǒng)架構(gòu)中，限界上下文(具體概念介紹見后面，這里你只需要理解為它類似于子系統(tǒng)或業(yè)務(wù)模塊劃分就好)是可以根據(jù)“業(yè)務(wù)子域”不是核心層，而分為“基礎(chǔ)層”和“業(yè)務(wù)價值層”。一般來說，“業(yè)務(wù)價值層”對應(yīng)到最核心的業(yè)務(wù)模塊，是一個軟件系統(tǒng)的核心競爭力所在，是需要嚴(yán)格按照 DDD 的理念進(jìn)行戰(zhàn)術(shù)設(shè)計(jì)、并采用測試驅(qū)動開發(fā)模式、投入最懂業(yè)務(wù)的程序員去工作的;而“基礎(chǔ)層”一般都是非核心業(yè)務(wù)模塊，比如：業(yè)務(wù)相關(guān)基礎(chǔ)類、工具類、伴生系統(tǒng)的對接等——需要注意的是：“基礎(chǔ)層”不是“基礎(chǔ)資源層”，基礎(chǔ)層指的是業(yè)務(wù)模塊處于非核心地位、而基礎(chǔ)資源指的是數(shù)據(jù)庫、中間件這些技術(shù)組件。

標(biāo)號 3 位置：這里顯示了多個限界上下文，都是以 xxxcontext 這樣的目錄取名。在“基礎(chǔ)層”和“業(yè)務(wù)價值層”中，都會出現(xiàn)多個“限界上下文”。每個限界上下文可以分離到不同的項(xiàng)目團(tuán)隊(duì)去負(fù)責(zé)、甚至分離到不同的微服務(wù)中心中。還是那句話，現(xiàn)在你還不用太深入的理解“限界上下文”，暫時只需要理解它是一種模塊劃分的說法就好(后面會逐步深入解釋)。

標(biāo)號 4 位置：這里顯示出來了“業(yè)務(wù)價值層”的代碼——也就是該軟件系統(tǒng)中需要作為最核心競爭力的那些模塊，同樣下面也會有多個“限界上下文”。

標(biāo)號 5 位置：DDD 戰(zhàn)術(shù)設(shè)計(jì)軟件分層的“菱形架構(gòu)”下，“領(lǐng)域”(domain)層的代碼放這里，也是業(yè)務(wù)邏輯最核心的代碼——所有的“充血”模型代碼。從這里開始，我們解釋某個“限界上下文”內(nèi)的代碼結(jié)構(gòu)。具體這些代碼怎么設(shè)計(jì)的細(xì)節(jié)，我們后面會講，現(xiàn)在你只需要知道這里放的是“業(yè)務(wù)邏輯核心”即可。

標(biāo)號 6、8 位置：在 DDD 戰(zhàn)術(shù)設(shè)計(jì)軟件分層的“菱形架構(gòu)”下，為了讓“限界上下文”在滿足外部的各種調(diào)用需求、以及需要調(diào)用或與別的“限界上下文”通訊時，不至于因?yàn)榕c本模塊業(yè)務(wù)邏輯無關(guān)的、各種外在因素變化而引起本模塊內(nèi)代碼邏輯的“動蕩不安”，而引入了“北向網(wǎng)關(guān)”、“南向網(wǎng)關(guān)”概念。分別說明如下：

標(biāo)號 6 就里面就是“北向網(wǎng)關(guān)”的代碼，里面又分為 local 和 remote 兩個典型的目錄?！氨毕蚓W(wǎng)關(guān)”的作用，就是讓限界上下文可以向外輸出各類應(yīng)用服務(wù)。local 目錄下方的是本限界上下文向外提供的“應(yīng)用服務(wù)”，是將 domain 內(nèi)各種“充血模型”代碼進(jìn)行封裝后的、完整的業(yè)務(wù)邏輯;而 remote 目錄下，放的是對 local 目錄為了滿足“遠(yuǎn)程調(diào)用”而進(jìn)行的代碼封裝——如 RPC 調(diào)用、跨服務(wù)器消息事件訂閱等，并不存在任何業(yè)務(wù)邏輯。

標(biāo)號 8 里面就是“南向網(wǎng)關(guān)”的代碼，里面又分為“端口(port)”和“適配器(adaper)”兩個典型的目錄。“南向網(wǎng)關(guān)”的作用，就是是讓本限界上下文通過其請求外部資源。典型的 3 類外部資源請求有：訪問數(shù)據(jù)持久層(關(guān)系或非關(guān)系數(shù)據(jù)庫)、調(diào)用別的限界上下文服務(wù)(在微服務(wù)架構(gòu)中，往往是 RPC 遠(yuǎn)程調(diào)用)、向別的限界上下文發(fā)布消息。我們都知道，這些對外部資源的請求，可能會因?yàn)橥獠抠Y源的技術(shù)底層不同，而存在不同的實(shí)現(xiàn)方式。為了能夠隔離“領(lǐng)域?qū)印睂唧w技術(shù)底層的依賴，就分離出來 port 層和 adapter 層。在 java 語言實(shí)現(xiàn)中，port 層就是 interface，沒有任何實(shí)現(xiàn)代碼，只有方法定義;而 adaper 層就是 implemetaion，具體實(shí)現(xiàn)到不同持久層(如不同關(guān)系數(shù)據(jù)庫 oracle/mysql 等、不同 nosql 數(shù)據(jù)庫 redis/mongodb 等)。然后，根據(jù) IoC(依賴倒置)原則在 java 中通過“依賴注入”來將 adaper 目錄下的具體實(shí)現(xiàn)與 domain 層的代碼連接起來。

標(biāo)號 7 位置：這里是“發(fā)布語言”(published language, pl)層。說白了，“發(fā)布語言”就是讓“北向網(wǎng)關(guān)”向外輸出服務(wù)時，能與服務(wù)調(diào)用者之間有個“統(tǒng)一語言”，比如：輸入輸出參數(shù)的結(jié)構(gòu)性定義、事件消息的格式定義等等。因?yàn)?，我們是不用將限界上下文?nèi)部的“領(lǐng)域”層的內(nèi)部對象結(jié)構(gòu)“泄露”到外部的，所以我們必須要有這個“發(fā)布語言”層。

3.結(jié)論

好了，解釋完了按照 DDD 進(jìn)行的代碼結(jié)構(gòu)設(shè)計(jì)，我們還是要回答一個問題：DDD 對真實(shí)世界進(jìn)行“同構(gòu)映射”后的代碼邏輯到底在哪里呢?

答案是：在“領(lǐng)域”(Domain)層里面!所謂的“北向網(wǎng)關(guān)”、“發(fā)布語言”、“南向網(wǎng)關(guān)”層的作用，都只是為了讓外部的請求、被請求資源的底層技術(shù)，不要去“打擾”我們“業(yè)務(wù)邏輯”的“同構(gòu)化”映射!

這就相當(dāng)于是說：領(lǐng)域?qū)硬攀?DDD 對“業(yè)務(wù)邏輯”映射后的核心，其它都只是對這些“核心業(yè)務(wù)邏輯”的層次“包裝”而已!

那么，顯然，從技術(shù)角度來說，懂得領(lǐng)域?qū)尤绾卧O(shè)計(jì)才是 DDD 戰(zhàn)術(shù)設(shè)計(jì)層面最重要的技能!因?yàn)?，“北向網(wǎng)關(guān)”、“發(fā)布語言”、“南向網(wǎng)關(guān)”這 3 層的代碼開發(fā)，都是常規(guī)套路，沒啥“業(yè)務(wù)知識”含量，甚至可以用機(jī)器人來實(shí)現(xiàn)(也就是通過代碼自動生產(chǎn)工具)。

最后，解釋下反復(fù)提到的 DDD 戰(zhàn)略設(shè)計(jì)和戰(zhàn)術(shù)設(shè)計(jì)的區(qū)別：

大體上來說，DDD 戰(zhàn)略設(shè)計(jì)，就是識別出有哪些限界上下文、以及清晰的定義限界上下文的關(guān)系和邊界，就基本完成了(雖然還有些修修補(bǔ)補(bǔ)的工作，比如要不要邊緣層、本軟件系統(tǒng)跟哪些第三方外部系統(tǒng)接口等，但這些其實(shí)已經(jīng)不能叫“設(shè)計(jì)”了，因?yàn)椴恍枰ǘ嗌倌X子了);

DDD 戰(zhàn)術(shù)設(shè)計(jì)，核心就是完成“領(lǐng)域”層內(nèi)的“聚合”、“領(lǐng)域服務(wù)”的設(shè)計(jì)，也就是“核心業(yè)務(wù)邏輯”的設(shè)計(jì)。具體怎么玩，我后面會一點(diǎn)點(diǎn)演示。