DDD 讓人感覺晦澀難懂，主要是因為DDD誕生之初，是一個純粹的理論體系，它包含了各種復雜且難以理解的概念，它那一堆名詞與理論，讓人看起來很費力。

今天我們來直擊其本質，讓你快速上手DDD 領域驅動設計，let's go！

1、什么是 DDD

DDD（Domain-Driven Design，領域驅動設計）是一種軟件設計方法，專注于通過深入理解業務領域來構建復雜的軟件系統。

DDD的核心思想是將業務需求與軟件設計緊密結合，通過建立清晰的領域模型，使開發人員和業務人員能夠以共同的語言交流，從而更好地解決業務問題。

簡單理解：DDD 不是架構，而是一種架構設計方法論，它通過邊界劃分將復雜業務領域簡單化，幫我們設計出清晰的領域和應用邊界，可以很容易地實現架構演進。

提到「架構演進」，我們就不得不提軟件架構模式的演進歷程。

2、軟件架構模式的演進

軟件架構模式的演進歷程是一個不斷適應技術發展和業務需求變化的過程，主要經歷以下三個階段：

• 單機架構：采用面向過程的設計方法，系統包括客戶端 UI 層和數據庫兩層，采用 C/S 架構模式，整個系統圍繞數據庫驅動設計和開發，并且總是從設計數據庫和字段開始。
• 集中式架構：采用面向對象的設計方法，系統包括業務接入層、業務邏輯層和數據庫層，采用經典的三層架構，也有部分應用采用傳統的 SOA 架構。這種架構容易使系統變得臃腫，可擴展性和彈性伸縮性差。

當然也有部分資料，將「集中式架構」分解為垂直架構/煙囪式架構 + 面向服務的架構（SOA） 兩部分

• 分布式微服務架構：隨著微服務架構理念的提出，集中式架構正向分布式微服務架構演進。微服務架構可以很好地實現應用之間的解耦，解決單體應用擴展性和彈性伸縮能力不足的問題。

圖片

DDD 是一種架構設計方法，微服務是一種架構風格。兩者都是為了拆解業務復雜度：合理劃分領域邊界，持續調整現有架構，優化現有代碼，以保持架構和代碼的生命力，也就是我們常說的演進式架構。

3、DDD 核心概念

DDD領域設計模型的核心概念：

• 領域（Domain）：業務問題的范圍，是DDD領域設計模型的基礎。
• 限界上下文（Bounded Context）：明確劃定的領域模型的邊界，它定義了領域內詞匯表和模型的范圍，使得在同一限界上下文內的開發人員能夠使用統一的語言進行交流。
• 實體（Entity）：領域中的核心概念，具有唯一標識，并隨時間變化其屬性。實體在領域模型中通常表現為對象，具有業務邏輯和狀態。
• 值對象（Value Object）：描述事物的對象，沒有唯一標識，主要用于描述領域中的某個方面或屬性。值對象通常用于傳遞參數或對實體進行補充描述。
• 聚合（Aggregate）：一組具有內聚關系的相關對象的集合，用于確保數據一致性。聚合根是聚合中的核心實體，負責維護聚合內部對象的一致性和完整性。

圖片

如何來劃定領域模型和微服務的邊界呢？

可以分三步來搞定~ (*^▽^*)

• 第一步：在事件風暴中梳理業務過程中的用戶操作、事件以及外部依賴關系等，根據這些要素梳理出領域實體等領域對象。
• 第二步：根據領域實體之間的業務關聯性，將業務緊密相關的實體進行組合形成聚合，同時確定聚合中的聚合根、值對象和實體。在上圖里，聚合之間的邊界是第一層邊界，它們在同一個微服務實例中運行，這個邊界是邏輯邊界，所以用虛線表示。
• 第三步：根據業務及語義邊界等因素，將一個或者多個聚合劃定在一個限界上下文內，形成領域模型。在上圖里，限界上下文之間的邊界是第二層邊界，這一層邊界可能就是未來微服務的邊界，不同限界上下文內的領域邏輯被隔離在不同的微服務實例中運行，物理上相互隔離，所以是物理邊界，邊界之間用實線來表示。

4、DDD 架構模型

三層架構向 DDD 四層架構演進，主要發生在業務邏輯層和數據訪問層。

圖片

DDD 四層架構包含用戶接口層、應用層、領域層和基礎層。

通過這些層次劃分，我們可以明確微服務各層的職能，劃定各領域對象的邊界，確定各領域對象的協作方式：

• 接口層（接入層、表示層）

職責：作為所有流量入口，負責接口定義和實現，同時還包括消息的監聽以及job的觸發入口。常見的接口類型包括grpc、http、mq、job等。

實踐：在Web應用中，接口層通常包含Controller類，并按不同的客戶端（如移動端、管理端、開放接口等）進行劃分。

• 應用層
• 職責：負責流程編排和差異化能力路由。它接收用戶請求，進行必要的校驗和調度，然后轉發給領域層處理，并將處理結果返回給用戶。
• 實踐：應用層通常包含服務編排類（如XxxAppService）、領域事件監聽器（如XxxListener）、實體工廠（如XxxFactory）等。
• 領域層
• 職責：包含系統的核心業務邏輯和規則，是DDD架構的核心。領域層與具體技術無關，不依賴其他各層，確保了業務邏輯的獨立性和可復用性。
• 實踐：領域層按領域聚合進行劃分，外部聚合按限界上下文（微服務）劃分。它定義了充血模型、值對象、倉庫接口、領域服務、領域事件等。領域契約（contract）包含API層特殊出入參、數據查詢參數、領域事件等。
• 基礎層
• 職責：與外部系統和資源交互，屏蔽外部特性，轉化成應用內識別定義的數據類型。它負責持久化機制實現、通用技術支持等。
• 實踐：基礎設施層包含倉庫層實現（如XxxRepositoryImpl）、外部服務實現（如封裝外部系統接口的引用，防止腐化領域模型）等。

5、DDD 應用挑戰

雖然 DDD 領域設計模型具備一些應用優勢，但它畢竟不是銀彈，同樣存在一些應用挑戰問題：

• 領域知識的獲取：建立準確的領域模型需要深入的業務知識和對領域的深入理解。這可能需要與業務專家進行大量的溝通和交流。
• 模型的復雜性：隨著業務領域的復雜性和規模的增加，領域模型可能會變得非常復雜和難以維護。
• 技術實現的挑戰：DDD領域設計模型的具體實現需要考慮到具體的技術框架和平臺，這可能會增加開發的難度和復雜性。

6、總結

整篇梳理下來，我覺得DDD不像一門技術，而更像是一種方法論，包含了很多設計理念。

知為行之始，行為知之成。準確做事的前提是準確的認知。

DDD領域設計模型是一種非常有效的軟件設計方法，它可以幫助開發人員更好地理解業務領域，并開發出符合業務需求的軟件系統。然而，在實際應用中，也需要考慮到領域知識的獲取、模型的復雜性和技術實現的挑戰等問題。