（一）什麼是領域驅動設計

什麼是領域驅動設計

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

• 軟件中的複雜性：包含「某種程度上確實有用但沒法解釋如何運行但代碼」。軟件變得複雜及難以管理但一個主要緣由在於，領域複雜性和技術複雜性混合在來一塊兒。

複雜問題域產生的緣由（泥球模式）

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

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

泥球模式的危害

• 1.泥球模式將扼殺開發：開發團隊會不斷抱怨在如此一團混亂的狀況下難以開展工做。開發速度的增加水平也沒法知足業務需求。
• 2.缺少對問題域的關注：當不能充分理解正在處理的業務領域時，軟件項目就會失敗。編碼不該該是困難的哪一環，維持一個可以知足業務用例的有用軟件模型纔是難點所在。

什麼是問題域

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

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

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

DDD 的戰略模式

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

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

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

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

• 3.使用公共語言開啓建模協做 模型使用公共語言構建（UML），以便快捷高效地將軟件模型和概念分析模型鏈接在一塊兒。編碼時的術語會被映射到公共語言中，在業務分析時隱藏的概念也會被反饋到代碼中。這正是領域專家和開發團隊可以在協做中逐步發展模型的關鍵。

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

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

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

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

DDD的戰術模式

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

問題空間與解空間

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

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

領域驅動設計的常見誤區

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

• DDD是一套框架

• DDD是銀彈

總結

不在與業務是否可以用到，關鍵是你是否具有某種能力。這個纔是付費的標準。