領域驅動設計是怎樣的

這篇文章給大家介紹領域驅動設計是怎樣的，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

領域驅動設計

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

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

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

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

• 1.未使用通用語言創建的代碼：對于公共語言和問題域知識缺乏重視會導致代碼庫可用但無法揭示業務目的，這會使得代碼庫難以閱讀和維護，因為分析模型與代碼模型之間的轉譯將會代價高昂且容易出錯。備注：分析模型：分析模型用于描述一個軟件應用程序的邏輯設計與結構。它可以由示意圖或使用UML這樣的建模語言來表示。它是軟件的一種表現形式，讓非技術人員能夠概念化以便理解軟件是如何構造的。

• 2.組織結構的缺乏：一個系統的最初體現是快速制作且通常能獲得面面俱到的成功，但由于缺乏基于圍繞問題域模型的應用程序設計的重視，后續的功能擴展就會變得很棘手。

• 
  

泥球模式的危害

• 1.泥球模式將扼殺開發：開發團隊會不斷抱怨在如此一團混亂的情況下難以開展工作。開發速度的增長水平也無法滿足業務需求。

• 2.缺乏對問題域的關注：當不能充分理解正在處理的業務領域時，軟件項目就會失敗。編碼不應該是困難的哪一環，維持一個能夠滿足業務用例的有用軟件模型才是難點所在。

什么是問題域

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

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

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

DDD 的戰略模式

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

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

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

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

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

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

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

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

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

DDD的戰術模式

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

問題空間與解空間

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

• 專注于核心領域

• 通過協作進行學習

• 通過探索和實驗來創建模型

• 通信

• 理解模型的適用性

• 讓模型持續發展

• 
  

領域驅動設計的常見誤區

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

• DDD是一套框架

• DDD是銀彈

  
  

關于領域驅動設計是怎樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。