【實踐篇】手把手教你落地DDD-有解無憂

1. 前言

常見的DDD實作架構有很多種，如經典四層架構、六邊形（配接器埠）架構、整潔架構（Clean Architecture）、CQRS架構等，架構無優劣高下之分，只要熟練掌握就都是合適的架構，本文不會逐個去講解這些架構，感興趣的讀者可以自行去了解，

本文將帶領大家從日常的三層架構出發，精煉推匯出我們自己的應用架構，并且將這個應用架構實作為Maven Archetype，最后使用我們Archetype創建一個簡單的CMS專案作為本文的落地案例，

需要明確的是，本文只是給讀者介紹了DDD應用架構，還有許多概念沒有涉及，例如物體、值物件、聚合、領域事件等，如果讀者對完整落地DDD感興趣，可以到本文最后了解更多，

2. 應用架構演化

我們很多專案是基于三層架構的，其結構如圖：

我們說三層架構，為什么還畫了一層 Model 呢？因為 Model 只是簡單的 Java Bean，里面只有資料庫表對應的屬性，有的應用會將其單獨拎出來作為一個
Maven Module，但實際上可以合并到 DAO 層，

接下來我們開始對這個三層架構進行抽象精煉，

2.1 第一步、資料模型與DAO層合并

為什么資料模型要與DAO層合并呢？

首先，資料模型是貧血模型，資料模型中不包含業務邏輯，只作為裝載模型屬性的容器；

其次，資料模型與資料庫表結構的欄位是一一對應的，資料模型最主要的應用場景就是DAO層用來進行 ORM，給 Service 層回傳封裝好的資料模型，供Service 獲取模型屬性以執行業務；

最后，資料模型的 Class 或者屬性欄位上，通常帶有 ORM 框架的一些注解，跟DAO層聯系非常緊密，可以認為資料模型就是DAO層拿來查詢或者持久化資料的，資料模型脫離了DAO層，意義不大，

2.2 第二步、Service層抽取業務邏輯

下面是一個常見的 Service 方法的偽代碼，既有快取、資料庫的呼叫，也有實際的業務邏輯，整體過于臃腫，要進行單元測驗更是無從下手，

public class Service {

    @Transactional
    public void bizLogic(Param param) {

        checkParam(param);//校驗不通過則拋出自定義的運行時例外

        Data data = https://www.cnblogs.com/jingdongkeji/p/new Data();//或者是mapper.queryOne(param);

        data.setId(param.getId());

        if (condition1 == true) {
            biz1 = biz1(param.getProperty1());
            data.setProperty1(biz1);
        } else {
            biz1 = biz11(param.getProperty1());
            data.setProperty1(biz1);
        }

        if (condition2 == true) {
            biz2 = biz2(param.getProperty2());
            data.setProperty2(biz2);
        } else {
            biz2 = biz22(param.getProperty2());
            data.setProperty2(biz2);
        }

        //省略一堆set方法
        mapper.updateXXXById(data);
    }
}

這是典型的事務腳本的代碼：先做引數校驗，然后通過 biz1、biz2 等子方法做業務，并將其結果通過一堆 Set 方法設定到資料模型中，再將資料模型更新到資料庫，

由于所有的業務邏輯都在 Service 方法中，造成 Service 方法非常臃腫，Service 需要了解所有的業務規則，并且要清楚如何將基礎設施串起來，同樣的一條規則，例如if(condition1=true)，很有可能在每個方法里面都出現，

專業的事情就該讓專業的人干，既然業務邏輯是跟具體的業務場景相關的，我們想辦法把業務邏輯提取出來，形成一個模型，讓這個模型的物件去執行具體的業務邏輯，這樣Service方法就不用再關心里面的 if/else 業務規則，只需要通過業務模型執行業務邏輯，并提供基礎設施完成用例即可，

將業務邏輯抽象成模型，這樣的模型就是領域模型，

要操作領域模型，必須先獲得領域模型，但此時我們先不管領域模型怎么得到，假設是通過loadDomain方法獲得的，通過 Service方法的入參，我們呼叫loadDomain方法得到一個模型，我們讓這個模型去做業務邏輯，最后執行的結果也都在模型里，我們再將模型回寫資料庫，當然，怎么寫資料庫的我們也先不管，假設是通過saveDomain方法，

Service層的方法經過抽取之后，將得到如下的偽代碼：

public class Service {

    public void bizLogic(Param param) {

        //如果校驗不通過，則拋一個運行時例外
        checkParam(param);
        //加載模型
        Domain domain = loadDomain(param);
        //呼叫外部服務取值
	    SomeValue someValue=https://www.cnblogs.com/jingdongkeji/p/this.getSomeValueFromOtherService(param.getProperty2());
        //模型自己去做業務邏輯，Service不關心模型內部的業務規則
        domain.doBusinessLogic(param.getProperty1(), someValue);
        //保存模型
        saveDomain(domain);
    }
}

根據代碼，我們已經將業務邏輯抽取出來了，領域相關的業務規則封閉在領域模型內部，此時 Service方法非常直觀，就是獲取模型、執行業務邏輯、保存模型，再協調基礎設施完成其余的操作，

抽取完領域模型后，我們工程的結構如下圖：

2.3 第三步、維護領域物件生命周期

在上一步中，loadDomain、saveDomain 這兩個方法還沒有得到討論，這兩個方法跟領域物件的生命周期息息相關，

關于領域物件的生命周期的詳細知識，讀者可以自行學習了解，

不管是 loadDomain 還是 saveDomain，我們一般都要依賴于資料庫，所以這兩個方法對應的邏輯，肯定是要跟 DAO 產生聯系的，

保存或者加載領域模型，我們可以抽象成一種組件，通過這種組件進行封裝模型加載、保存的操作，這種組件就是Repository，

注意，Repository 是對加載或者保存領域模型（這里指的是聚合根，因為只有聚合根才會有Repository）的抽象，必須對上層屏蔽領域模型持久化的細節，因此其方法的入參或者出參，一定是基本資料型別或者領域模型，不能是資料庫表對應的資料模型，

以下是 Repository 的偽代碼：

public interface DomainRepository {

    void save(AggregateRoot root);

    AggregateRoot load(EntityId id);
}

接下來我們要考慮在哪里實作DomainRepository，既然 DomainRepository 與底層資料庫有關聯，但是我們現在 DAO 層并沒有引入 Domain 這個包，DAO 層自然無法提供 DomainRepository的實作，我們初步考慮是不是可以將 DomainRepository 實作在 Service 層，

但是，如果我們在 Service 中實作DomainRepository，勢必需要在 Service 層操作資料模型：查詢出來資料模型再封裝為領域模型、或者將領域模型轉為資料模型再通過ORM 保存，這個程序不該是 Service 層關心的，

因此，我們決定在 DAO 層直接引入 Domain 包，并在 DAO 層提供 DomainRepository 介面的實作，DAO 層查詢出資料模型之后，封裝成領域模型供DomainRepository 回傳，

這樣調整之后， DAO 層不再向 Service 回傳資料模型，而是回傳領域模型，這就隱藏了資料庫互動的細節，我們也把DAO層換個名字稱之為Repository，

現在，我們專案的架構圖是這樣的了：

由于資料模型屬于貧血模型，自身沒有業務邏輯，并且只有Repository這個包會用到，因此我們將之合并到Repository中，接下來不再單獨列舉，

2.4 第四步、泛化抽象

在第三步中，我們的架構圖已經跟經典四層架構非常相似了，我們再對某些層進行泛化抽象，

Infrastructure

Repository 倉儲層其實屬于基礎設施層，只不過其職責是持久化和加載聚合，所以，我們將 Repository層改名為 infrastructure-persistence，可以理解為基礎設施層持久化包，

之所以采取這種 infrastructure-XXX 的格式進行命名，是由于 Infrastructure 可能會有很多的包，分別提供不同的基礎設施支持，

例如：一般的專案，還有可能需要引入快取，我們就可以再加一個包，名字叫infrastructure-cache，

對于外部的呼叫，DDD中有防腐層的概念，將外部模型通過防腐層進行隔離，避免污染本地背景關系的領域模型，我們使用入口（Gateway）來封裝對外部系統或資源的訪問（詳細見《企業應用架構模式》，18.1入口（Gateway）），因此將對外呼叫這一層稱之為infrastructure-gateway，

注意：Infrastructure 層的門面介面都應先在Domain 層定義，其方法的入參、出參，都應該是領域模型（物體、值物件）或者基本型別，

User Interface

Controller 層其實就是用戶介面層，即 User Interface 層，我們在專案簡稱 ui，當然了可能很多開發者會覺得叫UI好像很別扭，認為 UI就是 UI 設計師設計的圖形界面，

Controller 層的名字有很多，有的叫 Rest，有的叫 Resource，考慮到我們這一層不只是有 Rest 介面，還可能還有一系列 Web相關的攔截器，所以我一般稱之為 Web，因此，我們將其改名為 ui-web，即用戶介面層的 Web 包，

同樣，我們可能會有很多的用戶介面，但是他們通過不同的協議對外提供服務，因而被劃分到不同的包中，

我們如果有對外提供的 RPC服務，那么其服務實作類所在的包就可以命名為 ui-provider，

有時候引入某個中間件會同時增加 Infrastructure 和 User Interface，

例如，如果引入 Kafka 就需要考慮一下，如果是給 Service 層提供呼叫的，例如邏輯執行完發送訊息通知下游，那么我們再加一個包infrastructure-publisher；如果是消費 Kafka 的訊息，然后呼叫 Service 層執行業務邏輯的，那么就可以命名為 ui-subscriber，

Application

至此，Service 層目前已經沒有業務邏輯了，業務邏輯都在 Domain 層去執行了，Service 只是協調領域模型、基礎設施層完成業務邏輯，

所以，我們把 Service 層改名為 Application Service 層，

經過第四步的抽象，其架構圖為：

2.5 第五步、完整的包結構

我們繼續對第四步中出現的包進行整理，此時還需要考慮一個問題，我們的啟動類應該放在哪里？

由于有很多的 User Interface，所以啟動類放在任意一個User Interface中都不合適，放置在Application Service中也不合適，因此，啟動類應該存放在單獨的模塊中，又因為 application這個名字被應用層占用了，所以將啟動類所在的模塊命名為 launcher，一個專案可以存在多個launcher，按需參考User Interface，

加入啟動包，我們就得到了完整的 maven 包結構，

包結構如圖所示：

至此，DDD 專案的整體結構基本講完了，

2.6 精煉后的思考

在經過前面五步精煉得到這個架構圖中，經典四層架構的四層都出現了，而且長得跟六邊形架構也很像，這是為什么呢？

其實，不管是經典四層架構、還是六邊形架構，亦或者整潔架構，都是對系統應用的描述，也許描述的側重點不一樣，但是描述的是同一個事物，既然描述的是同一個事物，長得像才是理所當然的，不可能只是換一個描述方式，系統就從根本上發生了改變，

對于任何一個應用，都可以看成“輸入-處理-輸出”的程序，

“輸入”環節：通過某種協議對外暴露領域的能力，這些協議可能是 REST、可能是 RPC、可能是 MQ 的訂閱者，也可能是WebSocket，也可能是一些任務調度的 Task；

”處理“環節：處理環節是整個應用的核心，代表了應用具備的核心能力，是應用的價值所在，應用在這個環節執行業務邏輯，貧血模型由Service執行業務處理，充血模型則是由模型進行業務處理，

“輸出”環節，業務邏輯執行完成之后將結果輸出到外部，

不管我們采用的什么架構，其描述的應用的核心都是這個程序，不必生搬硬套非得用什么應用架構，

正如《金剛經》所言：一切有為法，如夢幻泡影，如露亦如電，應作如是觀；凡所有相，皆是虛妄；若見諸相非相，即見如來，

3. ddd-archetype

3.1 Maven Archetype介紹

Maven Archetype是一個Maven插件，可以幫助開發人員快速創建專案的基礎結構，大大減少開發人員在創建專案時所需的時間和精力，并且可以確保專案結構的一致性和可重用性，從而提高代碼質量和可維護性，

我們在介紹DDD應用架構時，對專案的結構進行了介紹，我們將專案分為多個Maven Module，如果每個專案都手工創建一次，是比較繁瑣的作業，也不利專案結構的統一，

我們使用Maven Archetype創建DDD專案初始化的腳手架，使其在初始化時完整實作上文第五步的應用架構，

3.2 ddd-archetype的使用

3.2.1 專案介紹

ddd-archetype是一個Maven Archetype的原型工程，我們將其克隆到本地之后，可以安裝為Maven Archetype，幫助我們快速創建DDD專案腳手架，

專案鏈接：

https://github.com/feiniaojin/ddd-archetype

3.2.2 安裝程序

以下將以IDEA為例展示ddd-archetype的安裝使用程序，主要程序是：

克隆專案-->archetype:create-from-project-->install-->archetype:crawl

3.2.3 克隆專案

將專案克隆到本地：

git clone https://github.com/feiniaojin/ddd-archetype.git

直接使用主分支即可，然后使用IDEA打開該專案

3.2.4 archetype:create-from-project

配置打開IDEA的run/debug configurations視窗，如下：

選擇add new configurations，彈出以下視窗：

其中，上圖中1～4各個標識的值為：

標識1 - 選擇"+"號；

標識2 - 選擇"Maven";

標識3 - 命令為：

archetype:create-from-project -Darchetype.properties=archetype.properties

注意，在IDEA中添加的命令默認不需要加mvn

標識4 - 選擇ddd-archetype的根目錄

以上配置完成后，點擊執行該命令，

3.2.5 install

上一步執行完成且無報錯之后，配置install命令，

其中，上圖中1～2各個標識的值為：

標識1 - 值為install；

標識2 - 值為上一步運行的結果，路徑為：

ddd-archetype/target/generated-sources/archetype

install配置完成之后，點擊執行，

3.2.6 archetype:crawl

install執行完成且無報錯，接著配置archetype:crawl命令，

其中，標識1中的值為：

archetype:crawl

配置完成，點擊執行即可，

3.3 使用ddd-archetype初始化專案

創建專案時，點擊manage catalogs：
將本地的maven私服中的archetype-catalog.xml加入到catalogs中：

添加成功，如下：

創建專案時，選擇本地archetype-catalog，并且選擇ddd-archetype，填入專案資訊并創建專案：
專案創建完成后：

4. 代碼案例

本文提供了配套的代碼案例，該案例使用DDD和本文的應用架構實作了簡單的CMS系統，案例專案采用前后端分離的方式，因此有后端和前端兩個代碼庫，

4.1 后端

后端專案使用本文的ddd-archetype創建，實作了部分CMS的功能，并落地部分DDD的概念，

GitHub鏈接：https://github.com/feiniaojin/ddd-example-cms

實作的DDD概念有：物體、值物件、聚合根、Factory、Repository、CQRS，

技術堆疊：

Spring Boot
H2記憶體資料庫
Spring Data JDBC

無外部中間件依賴，clone到本地即可編譯運行，非常方便，

4.2 前端

前端專案基于vue-element-admin開發，詳細安裝方式見代碼庫的README，

GitHub鏈接：https://github.com/feiniaojin/ddd-example-cms-front

4.3 運行截圖

5. 總結以及進一步學習

本文通過對貧血三層架構進行精煉，推匯出適合我們落地的應用架構，并且將之實作為Maven Archetype以應用到實際開發，然而應用架構只是落地DDD的一個知識點，要完整落地DDD還必須體系化地掌握限界背景關系、背景關系映射、充血模型、物體、值物件、領域服務、Factory、Repository等知識點，

作者：京東物流覃玉杰

內容來源：京東云開發者社區

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/553709.html

標籤：領域驅動設計

上一篇：系統設計：從零用戶擴展到百萬用戶

下一篇：返回列表