一、概述

DDD 是什么，DDD 的英文全稱是 Domain-Driven Design，翻譯過來就是領域驅動設計。

這種設計一般是用在微服務的系統中，當我們聊微服務的時候，爭論最多的就是如何進行微服務的拆分，這也是最讓人產生爭議的地方。

當我們聊微服務也必然會會聊到中臺，中臺又是什么呢？

中臺

中臺從 2015 年提出，就已經被我們熟知，但是每個人對中臺的認識可能都千差萬別，有沒有一個大家都比較認可的定義呢？

將通用的可復用的業務能力沉淀到中臺業務模型，實現企業級能力復用。

因此中臺面臨的首要問題就是中臺領域模型的重構。

而中臺落地時，依然會面臨微服務設計和拆分的問題。

• 微服務：中臺落地時需要用微服務進行支撐。
• 中臺：復用業務，實現企業級能力復用。
• DDD：對中臺進行領域建模，實現適合企業發展的中臺。

DDD 可以說是微服務和中臺的產品經理。我們去寫業務功能時，是面向領域的，而不是面向數據庫表來實現代碼的。

二、DDD 是什么？

DDD 的核心思想：是通過領域驅動設計方法定義領域模型，從而確定業務和應用邊界，保證業務模型與代碼模型的一致性。

DDD 是一種處理高度復雜領域的設計思想，它試圖分離技術實現的復雜性，并圍繞業務概念構建領域模型來控制業務的復雜性，以解決軟件難以理解，難以演進的問題。

戰略設計：主要從業務視角出發，建立業務領域模型，劃分領域邊界，建立通用語言的限界上下文，限界上下文可以作為微服務設計的參考邊界。

戰術設計：則從技術視角出發，側重于領域模型的技術實現，完成軟件開發和落地，包括：聚合根、實體、值對象、領域服務、應用服務和資源庫等代碼邏輯的設計和實現。

三、DDD 架構分層

首先我們來看下架構分層的原理圖：

用戶接口層

用戶接口層主要包含用戶界面、Web 服務。

用戶接口層負責向用戶顯示信息和解釋用戶指令。這里的用戶可能是：用戶、程序、自動化測試和批處理腳本等等。

應用層

應用層不應該有業務邏輯。它是很薄的一層，理論上不應該有業務規則或邏輯，主要面向用例和流程相關的操作。

應用服務是在應用層的，它負責服務的組合、編排和轉發，負責處理業務用例的執行順序以及結果的拼裝，以粗粒度的服務通過 API 網關向前端發布。還有，應用服務還可以進行安全認證、權限校驗、事務控制、發送或訂閱領域事件等。

領域層

領域層主要實現企業的核心業務邏輯，和之前的三層架構的 Service 層很像。

領域層當中又包含聚合，聚合里面就帶有聚合根、實體、值對象、領域服務等領域模型中的領域對象。

領域模型的業務邏輯主要通過實體和領域服務來實現，采用充血模型來時先所有與之相關的業務功能。充血模型后面會解釋。當單一實體(或值對象)不能實現時，領域服務就來進行聚合多個實體(或值對象)，來實現復雜的業務邏輯。

基礎層

基礎層為其他各層提供通用的技術和基礎服務，包括數據庫服務、消息中間件、對象存儲、緩存服務等。

它是封裝了所有的基礎服務，當切換基礎組件時，只用稍微修改下基礎服務就可以了。

比如之前用的對象文件存儲組件是阿里的，現在想換成騰訊的了，稍微改下基礎服務，切換成騰訊的就可以了，不用去改業務邏輯代碼。

這個就是采用了依賴倒置的原則，通過解耦來保持獨立的核心業務邏輯。

傳統三層架構轉 DDD 四層架構

傳統的三層架構就是 controller->service->model 這種模型，我們的思維習慣就是基于數據庫的表來開發業務功能。這種分層架構給開發人員帶來了便利，但是如果有其他人過來看你的代碼，他會很難從業務角度去理解，因為這些代碼都是為操作數據庫的表而寫。

有了 DDD 之后，代碼是面向業務功能的，而不是面向數據庫表的。

DDD 分層架構將業務邏輯層的服務拆分到了應用層和領域層。應用層快速響應前端的變化，領域層實現領域模型的能力。

三層架構數據訪問采用 DAO 方式、DDD 分層架構的數據庫等基礎資源訪問，采用了倉儲(Repository)設計模式，通過依賴倒置實現各層對基礎資源的解耦。

四、DDD 中各種 Object

• 數據持久化對象 (Persistent Object， PO)，與數據庫結構一一映射，它是數據持久化過程中的數據載體。
• 領域對象( Domain Object， DO)，微服務運行時核心業務對象的載體， DO 一般包括實體或值對象。
• 數據傳輸對象( Data Transfer Object， DTO)，用于前端應用與微服務應用層或者微服務之間的數據組裝和傳輸，是應用之間數據傳輸的載體。
• 視圖對象(View Object， VO)，用于封裝展示層指定頁面或組件的數據。
• 微服務基礎層的主要數據對象是PO。在設計時，我們需要先建立DO和PO的映射關系。大多數情況下DO和PO是一一對應的。但也有DO和PO多對多的情況。在DO和PO數據轉換時，需要進行數據重組。對于DO對象較多復雜的數據轉換操作，你可以在聚合用工廠模式來實現。當DO數據需要持久化時，先將DO轉換為PO對象，由倉儲實現服務完成數據庫持久化操作。當DO需要構建和數據初始化時，倉儲實現服務先從數據庫獲取PO對象，將PO轉換為DO后，完成DO數據構建和初始化。
• 領域層主要是DO對象。DO是實體和值對象的數據和業務行為載體，承載著基礎的核心業務邏輯，多個依賴緊密的DO對象構成聚合。領域層DO對象在持久化時需要轉換為PO對象。
• 應用層主要對象有DO對象，但也可能會有DTO對象。應用層在進行不同聚合的領域服務編排時，一般建議采用聚合根ID的引用方式，應盡量避免不同聚合之間的DO對象直接引用，避免聚合之間產生依賴。
• 在涉及跨微服務的應用服務調用時，在調用其他微服務的應用服務前，DO會被轉換為DTO，完成跨微服務的DTO數據組裝，因此會有DTO對象。在前端調用后端應用服務時，用戶接口層先完成DTO到DO的轉換，然后DO作為應用服務的參數，傳導到領域層完成業務邏輯處理。
• 用戶接口層主要完成DO和DTO的互轉，完成微服務與前端應用數據交互和轉換。facade接口服務在完成后端應用服務封裝后，會對多個DO對象進行組裝，轉換為DTO對象，向前端應用完成數據轉換和傳輸。facade接口服務在接收到前端應用傳入的DTO后，完成DTO向多個DO對象的轉換，調用后端應用服務完成業務邏輯處理。前端應用主要是VO對象。展現層使用VO進行界面展示，通過用戶接口層與應用層采用DTO對象進行數據交互。

五、領域分類

在研究和解決業務問題時，DDD 會按照一定的規則將業務領域進行細分，當領域細分到一定的程度后，DDD 會將問題范圍限定在特定的邊界內，在這個邊界內建立領域模型，進而用代碼實現該領域模型，解決相應的業務問題。簡言之，DDD 的領域就是這個邊界內要解決的業務問題域。

領域又可以分為多個子域，子域又包含核心域、通用域和支撐域。

• 核心域：核心業務，決定產品和公司核心競爭力的子域。
• 通用域：同時被多個子域使用的通用功能子域。
• 支撐域：支持其他子域，非核心域和通用域。

六、實現 DDD 流程

• 第一步：事件風暴，這里的風暴可以理解為頭腦風暴，領域專家會和設計、開發人員一起建立領域模型。
• 第二步：對領域中涉及到的場景(用戶故事)進行分析。
• 第三步：分析了場景之后，就要定義領域對象。設計實體、找出聚合根、設計值對象、設計領域事件、設計領域服務、設計倉儲。
• 第四步：領域對象需要包含業務邏輯，所以會形成一個代碼模型的映射。
• 第五步：根據代碼模型進行代碼落地。

六、限界上下文和通用語言

限界上下文

領域邊界就是通過限界上下文來定義的。

用來封裝通用語言和領域對象，提供上下文環境，保證在領域之內的一些術語、業務相關對象等(通用語言)有一個確切的含義，沒有二義性。

理論上限界上下文就是微服務的邊界。我們將限界上下文內的領域模型映射到微服務，就完成了從問題域到軟件的解決方案。

如果不考慮技術異構、團隊溝通等其它外部因素，一個限界上下文理論上就可以設計為一個微服務。

• 邏輯邊界：微服務內聚合之間的邊界是邏輯邊界。它是一個虛擬的邊界，強調業務的內聚，可根據需要變成物理邊界，也就是說聚合也可以獨立為微服務。
• 物理邊界：微服務之間的邊界是物理邊界。它強調微服務部署和運行的隔離，關注微服務的服務調用、容錯和運行等。
• 代碼邊界：不同層或者聚合之間代碼目錄的邊界是代碼邊界。它強調的是代碼之間的隔離，方便架構演進時代碼的重組。

通用語言

DDD 分析和設計過程中的每一個環節都需要保證限界上下文內術語的統一，在代碼模型設計的時侯就要建立領域對象和代碼對象的一一映射，從而保證業務模型和代碼模型的一致，實現業務語言與代碼語言的統一。

七、實體

實體概念

實體和值對象是組成領域模型的基礎單元。

類包含了實體的屬性和方法，通過這些方法實現實體自身的業務邏輯。

實體以 DO(領域對象)的形式存在，每個實體對象都有唯一的 ID。字段的值可以變。

實體是看得到、摸得著的實實在在的業務對象，實體具有業務屬性、業務行為和業務邏輯。

實體特點

有 ID 標識，通過 ID 判斷相等性，ID 在聚合內唯一。依附于聚合根，生命周期由聚合根管理。實體一般會持久化，但是與數據庫持久化對象不一定是一對一的關系。實體可以引用聚合內的聚合根、實體和值對象。

如下代碼所示，Product 屬于商品實體，有商品唯一 id。Location 屬于值對象，后面會講解值對象。

public class Product { // 商品實體
  private long id; // 值對象，商品唯一 id
  private String name; // 單一屬性值對象
  private Location location; // 屬性值對象，被實體引用
}

public class Location { // 值對象，無主鍵 id
  private String country; // 值對象
  private String province; // 值對象
  private String city; // 值對象
  private String street; // 值對象
}

實體類通常采用充血模型。

充血模型和貧血模型的區別

貧血模型：數據和業務邏輯分開到不同的類中，比如 Model 類和 Service 類。

充血模型：數據和業務邏輯封裝在同一個實體類中。

八、值對象

值對象概念

值對象描述了領域中的一件東西，這個東西是不可變的，它將不同的相關屬性組合成了一個概念整體。

值對象是 DDD 領域模型中的一個基礎對象，它跟實體一樣都來源于事件風暴所構建的領域模型，都包含了若干個屬性，它與實體一起構成聚合。

值對象只是若干個屬性的集合，只有數據初始化操作和有限的不涉及修改數據的行為，基本不包含業務邏輯。值對象的屬性集雖然在物理上獨立出來了，但在邏輯上它仍然是實體屬性的一部分，用于描述實體的特征。

值對象的特點

無 ID，不可變，無生命周期，用完就不需要了。值對象之間通過屬性值判斷相等性。核心本質是值，是一組概念完整的屬性組成的集合，用于描述實體的狀態和特征，值對象盡量只引用值對象。

九、聚合和聚合根

聚合

聚合就是由業務和邏輯緊密關聯的實體和值對象組合而成。

聚合是數據修改和持久化的基本單元，每一個聚合對應一個倉儲，實現數據的持久化。

聚合有一個聚合根和上下文便捷，根據業務單一職責和高內聚原則，定義了聚合內部應該包含哪些實體和值對象，而聚合之間的邊界是松耦合的。

聚合屬于 DDD 領域層，領域層包含多個聚合，共同實現核心業務邏輯。

聚合內的實體以充血模型實現個體業務能力，以及業務邏輯的高內聚。

跨多個實體的業務邏輯通過領域服務來實現，跨多個聚合的業務邏輯通過應用服務來實現。

特點：高內聚、低耦合，它是領域模型中最底層的邊界，可以作為拆分微服務的最小單位，但是不建議對微服務過度拆分。一個聚合可以作為一個微服務，以滿足版本的高頻發布和極致的彈性伸縮能力。一個微服務也可以包含多個聚合，可以進行拆分和組合。

聚合根

聚合根是為了避免由于復雜數據模型缺少統一的業務規則控制，從而導致聚合、實體之間數據不一致性的問題。

聚合可以比作組織，聚合根就是這個組織的負責人。

外部對象不能直接訪問聚合內實體，需要先訪問聚合根，再導航到聚合內部實體。

特點：聚合根是實體，有實體的特點，具有全局唯一標識，有獨立的生命周期。一個聚合只有一個聚合根，聚合根在聚合內對實體和值對象采用直接對象引用的方式進行組織和協調，聚合根和聚合根之間通過 ID 關聯的方式實現聚合之間的協同。

十、領域事件

領域事件用來表示領域中發生的事件。一個領域事件將導致進一步的業務操作，在實現業務解耦的同時，有助于形成完成的業務閉環。

領域事件驅動設計可以切斷領域模型之間的強依賴關系，事件發布完成后，發布方不必關心后續訂閱方事件處理是否成功，可以實現領域模型的解耦，維護領域模型的獨立性和數據的一致性。微服務之間的數據不必要求強一致性，而是基于事件的最終一致性。

領域事件的執行需要一系列的組件和技術來支撐：事件的構建和發布、事件數據持久化、事件總線、消息中間件、事件接收和處理。