領域驅動設計是一種設計思想，來源于 Eric Evans  的一本書 Domain-Driven Design –Tackling Complexity in the Heart of Software。它倡導通過建立領域模型來驅動軟件的設計，也就是從業務知識出發設計業務人員和技術人員都能理解的模型。

統一語言是領域驅動設計的關鍵概念之一。領域建模的核心難點就在于業務人員和技術人員使用了不同的概念（詞匯）來描述他們對軟件的理解。如果能使用同樣的語言交流，那么復雜軟件的設計就變得更加容易。

領域模型就是跨越業務領域作為問題空間和軟件解決方案空間的橋梁。

01 使用模型表達業務實體

使用模型來表達業務概念和知識，并指導數據庫、API 等軟件的進一步設計。模型思維是軟件工程中重要的思維之一，它可以簡化復雜問題，并從某一個視角出發讓人們更加容易理解問題。

模型是對現實世界的簡化，例如地圖就是一種有效的模型，幫助人們理解道路和街道。

領域模型就是對業務領域簡化的模型。

02 識別模型的邊界

領域模型集合之間由于業務的相關性可能形成松散的邊界，這些邊界就是我們分解復雜、大型問題為局部、消息問題的契機。

通過辨析模型的相關性，找到邊界就能為軟件模塊的劃分（單體架構）、服務的劃分（微服務架構）提供指導。

在領域驅動中，識別出來的邊界被稱為界限上下文。

03 識別聚合

在數據庫的關系模型中，模型為一張網絡結構。這樣對于代碼實現存在困擾，因為難以處理業務的一致性問題。例如，訂單、訂單項目、商品之間，訂單和訂單項目的關系更加密切，具有相同的業務生命周期。在領域驅動設計理念中，我們使用聚合代表一組模型的從屬關系，其中起到關鍵帶頭作用的模型被叫做聚合根，除此之外被叫做實體和值對象。

如果一個聚合只有一個實體，那么聚合根就是這個實體。

04 區分實體和值對象

除了聚合根和實體之外，有一些模型看起來就像一次性的，他們沒有自己的 ID 來標明身份，更多的是作為某個實體的一部分，表達幾個字段的集合。

例如，在電商系統中，用戶設定的常用地址，就是典型的實體，它有自己的 ID 作為身份。但當用戶為訂單選擇地址時，這時的地址只是訂單上的若干字段，我們就會把它處理為值對象。

05 操作模型

在領域驅動設計中，為了操作這些模型，又衍生了一些作為“操作者”的對象。

工廠：處理領域模型創建過程的對象，但有時候不是必須的。服務：用來處理某些業務邏輯的對象。例如，為訂單計算總價，或者校驗一些業務規則。倉儲：負責將領域模型持久化到數據庫中或從數據庫中重建的對象，它的目的是為了隔離領域模型和技術實現之間的差異。

06 對架構分層

為了更好的組織項目中各種各樣的對象，我們需要像計算機網絡一樣分層，來簡化復雜項目的復雜性。

在領域驅動設計中，推薦使用四層架構：

• 用戶接入層：處理用戶接入的數據結構，例如 RESTful API，或者事件。
• 應用層：處理用戶的業務操作邏輯，也就是用例，它和用戶的使用場景相關。
• 領域層：處理通用的領域邏輯，也就是較為專業的業務邏輯，例如訂單價格計算。
• 基礎設施層：用來和基礎設施適配，例如連接數據庫，操作 Redis等。

07 建立領域模型

為了從業務知識中提取出領域模型，人們發明了很多種方法。

事件風暴是一種流行的軟件建模方法。它的形式是通過工作坊引導業務人員和技術人員共同創作領域模型，以業務事件為線索，探索系統中可能的領域模型。

除了事件風暴之外，彩色建模也是一種常用的建模方法。它通過顏色區分不同領域模型的特點，來澄清領域模型的職責。彩色建模在過去的很多年里曾非常流行。