【實踐篇】手把手教你落地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 = 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=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等知識點。

作者：京東物流 覃玉傑

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