引言
領域驅動設計并不是新的架構設計理論，從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著重強調需要領域專家以便構造出專案依賴的統一語言和領域模型，但是如果專案的技術復雜性很高，領域能否理解是一種挑戰，當全體團隊成員沒有完全理解技術需求或限制時可能會導致問題
團隊過于重視戰術設計，導致實踐準線和原則的偏離
團隊對領域驅動設計的認知不夠，精力沒有聚焦在問題域拆分、統一語言、模型與技術關注點分離等核心原則上，而是一開始便從實作的角度觸發，過度強調戰術設計模式的落地，從而陷入無盡的技術細節之中
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/502746.html
標籤：其他