不容錯過！什麼是領域驅動設計？為什麼落地這麼難？

引言

領域驅動設計並不是新的架構設計理論，從 Eric Evans 提出至今已經有十多年曆史。由於微服務架構的興起，DDD 常用於指導微服務邊界劃分，並重新廣泛進入軟體研發大眾的視野。DDD 的理念及應用普及在國外相對成熟，在國內尚處於初期發展階段。國內的很多社群以及企業組織內部近幾年對於 DDD 的探討和應用逐漸火熱，許多架構師以及開發人員對 DDD 充滿了學習和實踐的熱情。而像敏捷一樣，不同團隊對其認知水平和實踐水平不盡相同，有的成功，大多數可能是失敗的。

領域驅動設計（Domain Driven Design），簡稱 DDD， Eric Evans 2004 年的《Domain-Driven Design: Tackling Complexity in the Heart of Software》一書中第一次提出。領域驅動設計是一種用於指導軟體設計的方法論，也是一種設計思維方式，用於解決軟體複雜性問題，旨在加速那些必須處理複雜領域的軟體專案的開發。

實踐 DDD 的第一步不在於如何編寫程式碼，而首先需要拉齊對領域驅動設計的認知。後續的系列文章將圍繞領域驅動設計進行不同視角探討，以期幫助大家對其有更深入的認識，並能應用的實際的研發工作中。

聊聊問題空間、解空間、領域模型

問題空間和解決方案空間





問題空間：Problem Space，是當前環境下業務所面臨的一系列問題和問題背後的需求，通常是業務和產品領域專家主導問題、需求的收集描述和分析。問題空間框定了我們要解決的問題的上下文，這種上下文環境不是軟體工程或是領域驅動所獨有的，而是通用的共性的元素。工程實踐必然處於某種上下文環境之下。

解決方案空間：Solution Space，解決方案空間是針對問題空間的解決方案，屬於工程實現階段，由技術專家主導方案設計。

軟體開發過程，本質上可以看作是問題空間到解決方案空間的一個對映轉化：問題空間，找出業務挑戰及其對相關需求場景用例分析解空間，透過具體的技術工具手段來進行設計實現

領域、模型和領域模型

領域：Domain

“領域” 是 “知識或活動的集合”，相對於軟體系統而言，領域就是軟體應用所要解決的現實問題區域。領域對應於問題空間，是一個特定範圍邊界內的業務需求的總和。

領域模型：Domain Model

抽象是一種化繁為簡的能力，是人類認識世界的利器，也是一種生物本能。在有限的腦容量的前提下，人類不可能儲存記憶所有的細節，海量資訊已經超出人腦儲存限制而無法容納和有效獲取。抽象使得人類可以遮蔽無關細節資訊，抽取高層的有效資訊進行記憶儲存。試想，如果腦機介面技術有所突破，在人腦背後連結的是海量的高效的計算機叢集，這種無限的儲存、計算和檢索能力的增強，“抽象能力也許會被弱化”。

模型被用來表述人們所關注的現實或想法的某個方面，本質上是一種抽象過程的產物，把與解決方案密切相關的方面抽象出來，而忽略無關細節。

聚焦在軟體工程領域，要想構建滿足需求的軟體系統，開發團隊需要軟體面向的領域所涉及的知識可能非常龐大和複雜，而模型正是解決這種資訊超載問題的有效工具。

對領域進行模型設計的過程就是領域建模，領域建模的目的並非是要建立一個百分之百符合 “現實” 的模型，理論上，我們也無法實現這種對現實的完全建模，而只能是對現實某種程度的模擬。

領域建模的輸出即領域模型，領域模型是針對特定領域裡的關鍵事物及其關係的視覺化表現，屬於解決方案空間範疇。為了準確定義需要解決問題而構造的抽象模型，為軟體系統的構建目標統一認知，是業務功能場景在軟體系統裡的對映轉化。領域模型並非領域專家頭腦中的知識，而是對這些知識進行嚴格的組織和有選擇的抽象。

同時，領域模型並非某種特殊的圖、文字或者程式碼，而是他們所傳達的思想，圖、文字或程式碼都可以作為模型的表示或傳達形式，但他們不是模型，而是不同維度的模型檢視。



領域驅動設計

領域驅動設計強調領域模型的重要性，並透過模型驅動設計來保障領域模型與程式設計的一致。領域驅動設計首先從業務需求中提煉出統一語言，並建立領域模型指導著程式設計以及編碼實現；最後，又透過重構來發現隱式概念，並不斷解決領域領域模型相關的新問題。本質上，領域驅動設計也是從問題空間對映到解決方案空間。

領域驅動設計結合了宏觀和微觀兩個層面的設計，分別對應於領域驅動概念中的戰略設計和戰術設計。

領域驅動設計：戰略設計

戰略設計的初衷是要保持模型的完整性，主要從下面兩個方面來考量的：

問題域方面：將問題規模進行拆解，劃分為不同型別的子域，識別出核心領域與其他子領域。

解決方案層面：劃分限界上下文和上下文對映對問題域進行合理的分解，確定上下文邊界以及它們之間的關係。

領域驅動設計：戰術設計

戰略設計的初衷是要保持模型的完整性，透過戰略設計將整個軟體系統分解為多個限界上下文，然後對每個界限上下文進行戰術設計。對每個限界上下文進行戰術設計。Eric Evans 提供的模型驅動設計的構造要素以及要素間的關係如下圖所示：



實體：Entity，不同於透過屬性進行定義的傳統物件，實體物件透過唯一標識進行區分，且具有持續的生命週期。

值物件：Value Object，值物件是具有屬性且不可變的物件，但沒有唯一標識。

領域事件：Domain Event，領域事件用於記錄系統內的模型活動相關的離散事件，雖然系統內所有事件都應該能夠被跟蹤，但只有被領域專家關心的事件型別才建立領域事件。

聚合：Aggregate，聚合物件是實體和值物件的聚合，聚合具有一個唯一的根，即聚合根。外部物件不再直接訪問聚合內部的單個物件或者實體，而是直接訪問聚合根，並使用聚合根將指令傳遞給對應的分組。

領域服務：Domain Service，某些領域邏輯不適合分配給某個特定的實體物件，可將其這些操作封裝成領域服務

資源庫：Repositories，資源庫不是配置庫，它提供一個全域性介面來訪問特定聚合內部所有的實體類和值物件，應該包括建立，修改，刪除聚合內部物件的方法。

工廠：Factories，工廠封裝了建立複雜物件和聚合的邏輯，對客戶端遮蔽建立的複雜性

上述 DDD 戰術設計的模式標識了進行設計時的一些關鍵模式，但並非說是一定要嚴格使用和遵循的，也不是遵循了所有的戰術設計模式就是符合領域驅動設計。因為，實踐 DDD 關鍵不在於這種戰術層面模式的落地，而是在於其宏觀的領域驅動設計思想的遵循，比如統一語言、領域模型與程式碼間的一致、子域及上下文的拆分以及對映、領域模型與技術關注點的分離等等。另外，隨著 DDD 的不斷髮展，一些新的構建模式已經湧現，老的構造模型不一定能符合團隊研發的要求。

領域驅動設計為什麼落地這麼難？

需要魯棒的領域知識，依靠專案中領域專家的支援

如果團隊中沒有熟悉應用所需領域知識的領域專家，即使具備技術再強的開發人員也無濟於事。在某些情形下，領域驅動設計需要一個或多個外部人員在整個軟體開發生命週期中扮演領域專家的角色。有些情況下，領域驅動設計需要在整個軟體開發生命週期中與外部團隊成員 (充當領域專家角色) 進行協作。

在創新型業務中應用 DDD 同樣存在挑戰，由於業務模式的不確定性，業務需求變化的頻率和幅度很大，同樣也缺乏新領域的領域專家，整個業務都處於一種探索模式，很難建立起相對穩定、高可複用的領域模型。

強調不斷迭代和持續整合，對缺乏迭代經驗而偏重於瀑布模型的團隊可能導致障礙

領域驅動設計實踐依賴不斷迭代和持續整合來構建高可擴充套件的專案，但是這種基於迭代和持續整合的時間，在某些團隊中落地可能會存在阻礙，特別是如果過去經驗是建立在僵化的開發模型上，比如瀑布模型。

不適合偏向技術型的應用

領域驅動設計適合於具有非常高領域複雜性 (業務邏輯複雜) 的應用，但不適用於領域複雜性很低但技術複雜性很高的領域。DDD 著重強調需要領域專家以便構造出專案依賴的統一語言和領域模型，但是如果專案的技術複雜性很高，領域能否理解是一種挑戰。當全體團隊成員沒有完全理解技術需求或限制時可能會導致問題

團隊過於重視戰術設計，導致實踐準線和原則的偏離

團隊對領域驅動設計的認知不夠，精力沒有聚焦在問題域拆分、統一語言、模型與技術關注點分離等核心原則上，而是一開始便從實現的角度觸發，過度強調戰術設計模式的落地，從而陷入無盡的技術細節之中。

作者：倪新明