領域驅動設計 Domain-Driven Design

此系列文章為「領域驅動設計：軟體核心複雜度的解決方法 (Domain-Driven Design: Tackling Complexity in the Heart of Software)」一書閱讀心得與原理解析，提供《商業級 ASP.NET MVC 樣式與架構實務》一書延伸學習

。 領域驅動設計（DDD）- 分層設計
。 領域描述與模型組成
。 領域知識與模型 - 實體
。 領域知識與模型 - 實體與實值物件
。 領域知識與模型 - 服務
。 組織領域模型與聚合概念
。 領域模型與工廠樣式
。 Repositories I - Why
。 Repositories II - How To

開發軟體的目的，是為了解決真實世界中，各種領域（domain）的問題，因此，軟體必須依據特定領域所要處理的問題作設計，在這個前提下才能開發出真正優秀的軟體，然而在資訊科技領域，無論系統分析師，或是程式開發人員，都無法真正瞭解所要處理的問題，我們必須透過問題相關領域（domain）專家的協助，瞭解處理問題所需的專業知識，逐步將這些知識，轉換為軟體架構。

例如處理銀行交易的軟體，我們會需要金融領域的專家協助，如果開發的是教學軟體，則需尋求教育領域的專家、老師的合作，以釐清需求，因此軟體開發的成敗，將會有很大的程度取決於是否貼近領域現實，「領域驅動設計 Domain-Driven Design」理論，可以協助開發人員透過各種技巧，實踐領域優先模式的軟體開發流程。

「領域驅動設計」最早出現於 2003 年 Eric Evans 出版的同名書「領域驅動設計：軟體核心複雜度的解決方法 (Domain-Driven Design: Tackling Complexity in the Heart of Software)」，其主張在面對複雜軟體設計的情形下，依據特定領域知識進行軟體開發設計，透過獨立功能物件的拆分與聚合，降低軟體開發的複雜度，並提升軟體未來發展的延展性。

一般在軟體開發的過程中，領域專家並不懂技術，資訊工程人員透過不斷的討論與溝通，抽象化領域知識，進一步轉化成描述領域問題的模型，然後根據模型發展軟體架構，撰寫程式碼，建立解決問題的軟體流程。

「領域驅動設計」中，領域模型是軟體開發最重要的關鍵。

單一模型的設計並不複雜，困難的在於如何透過模型組織領域知識，以利後續撰寫程式碼解決所要處理的問題，在這個過程中，我們必須能夠系統化的組織並且整合獨立模型，進一步群組化，形成聚合模組，這些過程是「領域驅動設計」最大的挑戰。

建構模型的另外一個難題，在於這些模型除了作為軟體開發過程的依據，另外必須同時能夠被用來與非技術背景的領域專家溝通，也因此我們需要可以跨領域的通用語言。

軟體設計有不同的方法邏輯理論，這其中各有不同的優缺點，重點都在降低軟體設計的複雜度，而「領域驅動設計」可以讓我們將其維持在可以控管的程度，無論採用的是何種設計邏輯。

「領域驅動設計」一詞出現至今將近 20 年，日益複雜的開發環境，反而突顯其在軟體發展過程中的重要性，而當年「領域驅動設計」一書，作者僅僅透過文字敘述「領域驅動設計」理論，並沒有真正實作的程式碼與具體作法，事實上透過早期的技術，要完全實踐其理論無疑是個浩大的工程，尤其關聯式資料庫的SQL技術與程式語言的相容問題，更進一步增加「領域驅動設計」的難度，幸運的是，微軟透過LINQ技術的導入，降低了領域導向設計所需的技術門檻，而 Entity Framework 的出現，更是讓複雜商業應用的開發，完完全全的領域驅動導向了，也因此當我們要利用 ASP.NET MVC 進行商業應用開發，LINQ+Entity Framework 的技術組合需先熟練不可，最後才能順利的結合 APS.NET MVC 進行特定領域的 Web 應用開發。