原文鏈接：https://airbrake.io/blog/software-design/domain-driven-design
進一步擴展前面我們討論的面向對象分析和設計（OOAD），這篇文章討論領域驅動設計(DDD)，DDD是建立在面向對象分析設計上開發軟件的一種方法。 通過這篇文章我們解釋什麼是領域驅動設計，在現代開發週期中如何實現，使用DDD的優點和缺點。
什麼是領域
定義DDD之前我們首先必須要說明在開發中”領域”的含義。領域在字典中的解釋是：“活動或者知識的範圍”，更深層次的來講，軟件工程中領域指的是軟件應用的地方。 換句話說,在軟件開發中,領域指的是”應用程序邏輯範圍的知識和活動”
另一個在軟件開發中常使用的術語是領域層或領域邏輯，對於開發者來說，說成是業務邏輯或許應該會更加熟悉。應用程序業務邏輯指的是業務對象如何與其他業務對象交互（如何生成對象，修改相關數據）這種更高級別的規則。
什麼是領域驅動設計
最先介紹領域驅動設計的是在程序員 Eric Evans 2004年出版的《領域驅動設計:複雜軟件核心複雜應對之道》書籍中，領域驅動設計是領域概念的擴展和應用，並且將它應用在軟件開發中。它的目標是將軟件相關部分連接到不斷髮展的模型中，以此更容易創建複雜的應用，DDD關注三個核心點：
.關注核心領域和核心領域邏輯。
.在領域模型中進行複雜性設計。
.與領域專家緊密合作，以此改進應用模型和解決新出現的領域問題。
Evans的《領域驅動設計：複雜軟件核心複雜性解決之道》一書中定義了幾個常用的術語，在實踐DDD和討論DDD的時候非常有用。
.Context(上下文)：單詞或者語句出現的環境，它決定了單詞或語句的含義。關於模型的語句只能在上下文中理解。
.Model(模型)：一個系統的抽象，用於描述領域的某個方面，並且能夠用於解決領域相關的問題。
.Ubiquitous Language(統一語言)：與領域模型相關的結構化語言，用於將團隊成員的活動與軟件連接起來。
.Bounded Context(上下文邊界)：模型定義的範圍和適用範圍的描述（比如，子系統，特定團隊的工作）。
構建塊
領域驅動設計同樣也定義了幾個連接領域模型的高層次概念，以此來修改，創建領域模型。
.Entity（實體）：連續狀態變化的對象，而不是傳統使用屬性來定義的對象。
.value object（值對象）：一個不可變且有屬性的對象，但是它沒有唯一的標識符。
.Domain Event（領域事件）：系統內記錄與模型活動相關的分離事件的對象，系統內所有的事件都應該能夠被跟蹤，一個領域事件僅被領域專家關心的事件類型創建。
.Aggregate（聚合）：根據組邊界定義值對象和實體的聚合, 而不是允許單個實體或者值對象執行它自己所有的動作，聚合的對象都有一個統一的根對象（在書籍中寫的是選擇一個實體作爲根），這樣，外部對象不再直接訪問聚合內部的單個對象或者實體，而是直接訪問單一的聚合根對象，並且使用這個對象將指令傳遞給對應的分組。這個實踐和設計模式編碼相關聯。
.Service（服務）：本質上是來說，一個服務就是一個操作或者業務邏輯的組合，這樣就表明了它在對象領域中不適用。換句話來說，如果某些功能必須存在且不能和實體或者值對象相關聯，它可以定義爲服務。
.Repositories（倉庫）：不要和常見的版本控制倉庫相混淆，倉庫在DDD裏面的意思就是一個服務，它提供一個全局接口來訪問特定聚合內部所有的實體類和值對象。應該包括創建，修改，刪除聚合內部對象的方法。然而，通過使用倉庫服務來構造數據查詢的目的是刪除業務邏輯對象模型中的數據查詢方法。
.Factories（工廠）：正如我們在設計模式文章裏面討論的那樣，DDD建議使用工廠來創建複雜對象和聚合，保證客戶端不用知道對象內部組成。
同樣，DDD也着重強調越來越流行的持續集成實踐，它要求所有開發團隊使用同一個倉庫共享代碼，並且每天推送代碼到倉庫。在每天結束的時候自動檢查代碼倉庫完，運行單元測試，迴歸測試等過程。這樣就可以快速檢測出潛在存在的問題並在下一次提交代碼的時解決這個問題。
領域驅動設計優點
.溝通簡單：團隊成員使用與領域模型相關的統一語言來溝通會更加容易。通常來說，在討論應用程序時DDD使用更少的技術行業術語，因爲在先前建立的統一語言定義了更簡單的術語來指代哪些更具有技術性的術語。
.提高靈活性：DDD基於面向對象分析和設計相關的概念，幾乎領域模型內的任何東西都基於對象，因此十分便於分模塊。這就可以對各個組件，整個系統作出持續性的修改。
.在接口上強調領域：DDD是圍繞領域概念和領域專家建議進行構建的實踐活動，與哪些首先強調UI/UX的應用程序不同，DDD總是會生成適合當前領域的應用程序。雖然需要明顯的平衡，但是聚焦於DDD意味者能夠產生一個與該領域用戶有共鳴的產品。
領域驅動設計的缺點
.需要精力充沛的領域專家：即使有最精通技術的開發人員，如果團隊內沒有一個知道應用程序使用領域相關的領域專家，那也是沒有意義的。在某些情形下，領域驅動設計需要一個或多個外部人員在整個軟件開發生命週期中扮演領域專家的角色。
.鼓勵迭代實踐：雖然許多人覺得這是一個優勢，不可否認，DDD實踐強烈依賴連續迭代和持續集成來構建易於修改的項目。某些團隊在實踐這個的時候可能會遇到問題，特別是那些過去經驗與不太靈活的開發模型有關，比如瀑布模型。
.不適用偏向技術型的項目：DDD適用於領域複雜的應用(業務邏輯複雜)，它不適用於邊界複雜的領域，類似這種領域都有高的技術複雜性。DDD着重強調需要領域專家生成正確的統一語言並且一起寫出項目的領域模型，但是領域專家來極難把握具有極高技術複雜性的項目，因此可能導致全體團隊成員沒有完全理解技術上的要求和限制。