什麼是領域驅動設計

領域驅動設計是Eric Evans 定義的一種發展理念，

• 軟體中的複雜性：包含“某種程度上確實有用但無法解釋如何執行但程式碼”。軟體變得複雜及難以管理但一個主要原因在於，領域複雜性和技術複雜性混合在來一起。

複雜問題域產生的原因（泥球模式）

軟體複雜性：偶發性技術複雜性和領域邏輯複雜性。

• 1.未使用通用語言建立的程式碼：對於公共語言和問題域知識缺乏重視會導致程式碼庫可用但無法揭示業務目的，這會使得程式碼庫難以閱讀和維護，因為分析模型與程式碼模型之間的轉譯將會代價高昂且容易出錯。備註：分析模型：分析模型用於描述一個軟體應用程式的邏輯設計與結構。它可以由示意圖或使用UML這樣的建模語言來表示。它是軟體的一種表現形式，讓非技術人員能夠概念化以便理解軟體是如何構造的。
• 2.組織結構的缺乏：一個系統的最初體現是快速製作且通常能獲得面面俱到的成功，但由於缺乏基於圍繞問題域模型的應用程式設計的重視，後續的功能擴充套件就會變得很棘手。

泥球模式的危害

• 1.泥球模式將扼殺開發：開發團隊會不斷抱怨在如此一團混亂的情況下難以開展工作。開發速度的增長水平也無法滿足業務需求。
• 2.缺乏對問題域的關注：當不能充分理解正在處理的業務領域時，軟體專案就會失敗。編碼不應該是困難的哪一環，維持一個能夠滿足業務用例的有用軟體模型才是難點所在。

什麼是問題域

問題域涉及你當前正在構建軟體的主題領域。DDD強調的是在致力於為大型複雜業務系統建立軟體時專注領域要高於其他的一切的需求。

領域驅動設計模式如何管理複雜性

DDD 能同時應對理解問題域以及建立有助於解決其內在的問題的可維護解決方案的挑戰。

DDD 的戰略模式

• 1.提煉問題域已揭示重要之處是什麼。

  開發團隊與領域專家會使用分析模式和知識處理來將大的問題域提煉成更具管理性的子域。核心領域是出於開發過程的產品背後的驅動力；它是構造產品的根本原因。

  探索核心領域有助於團隊理解他們製作軟體的原因以及軟體對業務達成的成就意味著什麼。對業務目標的鑑定將使得開發團隊能夠確定系統的重要部分併為之投入精力。隨著業務的發展，軟體也必須相應發展；它需要具備可修改能力，對應用程式關鍵區域的程式碼質量進行投入將有助於應用程式跟上業務的變化節奏。

• 2.建立一個模型以解決領域問題 在解空間中，會為每一個子域構建一個軟體模型以處理領域問題並讓軟體與業務保持一致。該模型並非現實世界的模型，而更多的是構建來滿足業務用例需求的一個抽象體，同時仍保持業務領域的規則和邏輯。

• 3.使用公共語言開啟建模協作 模型使用公共語言構建（UML），以便快捷高效地將軟體模型和概念分析模型連線在一起。編碼時的術語會被對映到公共語言中，在業務分析時隱藏的概念也會被反饋到程式碼中。這正是領域專家和開發團隊能夠在協作中逐步發展模型的關鍵。

• 4.將模型與歧義和損壞隔離 模型位於有界上下文內，定義了模型的適用性並確保保留其完整性。有界上下文用於形成一個圍繞模型的防護邊界，這是通過允許總體解決方案的不同模型在良好定義的業務上下文內部逐步發展來達成的，這樣就不會帶來對系統其他的負面連鎖影響。

模型是與基礎架構程式碼隔離的，以避免技術與業務概念融合的偶發複雜性。通過將模型完整性與第三方程式碼隔離，有界上下文還能阻止模型完整性被損壞。

• 5.理解上下文之間的關係

DDD 理解確保團隊和業務在獨立模型和上下文如何共同工作以便解決跨越子域的領域問題方面要非常清楚的需求。

DDD的戰術模式

DDD的戰術模式是一個幫助建立用於複雜有界上下文的有效模型的模式集合。(企業應用架構模式 ,設計模式)

問題空間與解空間

領域驅動設計的實踐與原則

• 專注於核心領域
• 通過協作進行學習
• 通過探索和實驗來建立模型
• 通訊
• 理解模型的適用性
• 讓模型持續發展

領域驅動設計的常見誤區

• 戰術模式是DDD的關鍵 對於開發人員來說，在開發人員不關心或不理解的領域方面，發現在程式碼中實現的DDD戰術模式遠比發現業務使用者和團隊之間的會話要容易多。這就是DDD會被誤認為不過是由實體，值物件和儲存庫構成的一種模式語言。

• DDD是一套框架

• DDD是銀彈

總結

不在與業務是否能夠用到，關鍵是你是否具備某種能力。這個才