DDD領域驅動設計實戰(一)-領域模型、子域、核心域、通用域和支撐域等基本概念

1 領域

用以确定邊界。

DDD按規則細分業務領域，細分到一定程度，DDD會将問題範圍限定在特定邊界，在該邊界内建立領域模型，進而用代碼實作該領域模型，解決相應業務問題。

領域就是該邊界内要解決的業務問題域。其越大，則業務範圍越廣。

領域模型的特點

對業務領域模組化：

• 細粒度的類，易擴充，易複用
• 可應對複雜業務邏輯
• 需要經驗

簡單的領域模型：

• 幾乎和DB中的表一一對應
• 複雜領域模型
• 使用了繼承，組合，設計模式等各種手段

2 子域

領域可再劃分為多個子領域，即子域。

每個子域對應一個更小的問題域或業務範圍。

DDD是處理複雜領域的設計思想，它試圖分離技術實作的複雜度。每個細分的領域都有一個知識體系，即DDD的領域模型。在所有子域研究完後，就建立了領域模型。

比如酒店行業，一開始的酒店核心系統是單體架構，後來業務發展，開始轉型中台，引入微服務。微服務架構就需劃分業務領域邊界，建立領域模型，并實作微服務落地。

可根據業務關聯度及流程邊界将酒店領域細分為：預訂，入住，退房，客房服務，點餐等領域事件。

• 網上預訂，入住，退房。是酒店領域一定要有的功能，這就是核心子域。
• 客房服務，點餐等不影響主要功能的就是支撐子領域。
• 在預訂這個限界上下文内可以建立預訂的領域模型的領域模型最後映射到系統就是預訂微服務。

不同行業的業務模型可能不同，但領域模組化過程類似，核心思想都是将問題域逐漸分解，降低業務了解和系統實作的複雜度。

實際項目劃分出的子域更多，但并非每個子域都一樣重要。是以，還要繼續劃分子域，根據自身重要性和功能屬性劃分為：

2.1 核心域（Core Domain）

決定業務成功和公司核心競争力的子域，整個系統最重要部分。

Eric Evans 曾提出如下問題助識别核心域：

• 為什麼這個系統值得寫？
• 為什麼不直接買一個？
• 為什麼不外包？

若你對這幾個問題的回答能夠幫你找到這個系統非寫不可的理由，那它就是你的專屬核心域。

2.2 支撐域（Supporting Subdomain）

不是你的核心競争力，但又不得不做，市場上也找不到現成方案的子域。既不包含決定産品和公司核心競争力的功能，也不包含通用功能的子域，但又必需。

支撐域具有企業特性，但不具通用性，如：

• 資料代碼類的資料字典等系統
• 要做一個排行榜，可能根據各種資訊排名，這種東西沒人會按你需要做個，但對你自己，又是擴充自己系統的重要舉措

2.3 通用域（Generic Subdomain）

沒有太多個性化需求，同時被多個子域使用的通用功能子域。比如認證、權限等，無企業特點限制，無需太多定制化。

行業裡都這麼做，即便不自己做，也不影響業務運作。如很多 App 要給使用者發通知，這種功能完全可買個服務，絲毫不影響業務運作。

2.4 劃分子域的意義

劃分子域就是在區分不同概念，讓他們各司其職。為了區分不同子域在公司内的不同功能屬性和重要性，進而公司可對不同子域采取不同的資源投入和建設政策，其關注度和資源投入政策不同：

• 核心域全力投入
• 支撐域次之
• 通用域甚至可以直接花錢買服務

3 總結

領域的核心思想是将問題域逐級細分，降低業務了解和系統實作的複雜度。

通過領域細分，逐漸縮小微服務需要解決的問題域，建構合适的領域模型，映射成系統就是微服務。