DDD領域驅動最全詳解(圖文全面總結)

來源：mikechen的網際網路架構

DDD是現在非常火熱的，而且大廠面試也經常考察，下面我就全面來詳解DDD領域驅動設計

什麼是DDD架構

DDD全稱是Domain-Driven Design，翻譯過來就是領域驅動設計，DDD 架構是一種軟體設計方法論。

如下圖所示：

DDD架構的作用

DDD架構透過邊界劃分，將複雜業務領域簡單化，幫助我們設計出清晰的領域和應用邊界。

以下是領域驅動設計的一些主要作用和好處：

1.更好的業務理解和溝通

DDD 強調透過領域模型來表示業務領域，這有助於團隊成員更深入地理解業務規則、需求和概念。

2.模組化和可維護性

DDD 強調在開發中構建清晰的模組，如聚合和實體，這種模組化設計有助於程式碼的可維護性。

3.更好的架構設計

DDD 提供了一些模式和概念，比如：聚合、限界上下文等，有助於設計出更合適的架構。

4.減少重複勞動

透過建立可重用的領域模型和模組，可以減少開發過程中的重複勞動，這有助於提高開發效率並降低錯誤率。

DDD分層架構

DDD最有標誌性的一點，就是將傳統軟體設計三層模型轉化為了四層模型，這個轉化如下圖所示：

主要分為如下四層：

1.使用者介面層

網路協議的轉化/統一鑑權/Session管理/限流配置/前置快取/異常轉換

2.應用層

業務流程編排（僅編排，不能存在業務邏輯）/ DTO出入轉化

3.領域層

領域模型/領域服務/倉儲和防腐層的介面定義

4.基礎設施層

倉儲和防腐層介面實現/儲存等基礎層能力

DDD架構設計

DDD架構的一些核心設計和原則：

1.領域

指業務領域的知識和規則，DDD 關注於將這些領域知識對映到軟體模型中，以便更好地理解業務需求。

領域越大，業務的範圍也越大，大的領域可以拆分成小的問題域，稱之為子域。

根據子域重要性和功能屬性劃，可以將其分為三類。

1. 核心域：決定產品核心競爭力的子域；

2. 支撐域：實現核心域目標所需的，但重要程度不如核心域的子域，一般具備強烈的個性化需求；

3. 通用域：具有通用功能，可被多個子域使用的的是通用域。

2.限界上下文

限界上下文是在整個系統中定義一致的領域模型的邊界，不同的上下文可能有不同的模型和語言，但在各自範圍內是一致的。

主要體現在如下幾點：

1. 限界上下文是領域概念的語言邊界與業務邊界，在這個邊界內領域概念的內涵是清晰、無歧義的。

2. 限界上下文是團隊的工作邊界，組織邊界與限界上下文對齊。

3. 限界上下文是技術方案的實施邊界，在這個邊界內，技術方案是獨立自治的，業務邏輯不會落入不同技術邊界的間隙。

3.模型驅動設計

DDD 強調構建貼近領域模型的軟體設計，模型作為核心驅動開發過程，模型用於表達領域概念、業務規則和關係。

模型驅動設計的關鍵思想是：

1. 深入理解領域：開發團隊需要深入瞭解業務領域，與領域專家合作，以便捕捉業務中的核心概念、規則和業務流程。

2. 建立領域模型：基於對領域的理解，團隊將業務概念和規則轉化為領域模型，這些模型可以是類、物件、關係圖等，用於表達領域的核心特性。

3. 模型驅動設計：開發過程中，團隊將領域模型作為設計和實現的主要依據，比如：程式碼、資料庫設計等都基於領域模型進行構建。

4. 持續迭代和反饋：在開發過程中，團隊根據實際情況不斷調整和完善領域模型，這包括了與領域專家的持續交流和迭代。

4.聚合

聚合是相關物件的集合，具有內部一致性邊界，在 DDD 中，聚合是資料和業務邏輯的組織單元，透過聚合根來管理狀態變更。

每一個聚合有一個聚合根實體，設定聚合根的主要目的是為了避免由於複雜資料模型缺少統一的業務規則控制，而導致聚合、實體之間資料不一致性的問題。

建議的聚合設計原則：

1. 在一致性邊界之內確保不變性：聚合用來封裝真正的不變性，而不是簡單地將物件組合在一起。

2. 設計小聚合：如果聚合聚合包含過多的實體，會提高管理實體的複雜性，高頻操作下容易併發衝突，降低了系統的效能。

3. 在邊界之外使用最終一致性：不同的聚合之間不要求強一致性，保證最終一致性。

5.實體

實體是擁有唯一標識的物件，具有生命週期和狀態，它們用於表示領域中的有關事物。

比如：在校園教務系統中，每個賬戶是對應著一個學生，根據學號來唯一標識，可以認為是一個實體。

6.值物件

值物件是沒有唯一標識的物件，通常用於描述一些屬性或特性。

比如：地址資訊{“省”: “廣東省”，”市”:”深圳市”}，透過物件屬性值來識別的物件，則可以認為是一個值物件。

7.領域服務

服務是表示領域中的一些操作或功能，不能被清晰地歸類為實體或值物件，它們用於處理跨實體的業務邏輯。

舉個例子：在一個路線導航的專案中，“路線”可能是其中的一個實體，如果業務中有“推薦路線上相關的美食”這樣一個功能。

那我們會想，這個功能應該歸給哪個領域物件，給“路線”實體嗎？有點不合適，應該路線本身關注的是起終點，時間人物等。

此時可以將其這個功能歸為領域服務，它是一個路線狀態無關的服務，輸入路線各個節點，來得到沿路的各種美食。