DDD的基本概念澄清
目錄
什麼是DDD
•Domain Driven Design
•領域是軟件要解決的問題區域
•通過對領域知識建立模型，形成團隊內各成員的通用語言，指導設計和實現，從而達到爲客戶解決問題的目的
•當領域模型發生改變時，開發人員需要重構，以便反映模型的變化，這樣新知識就合併到軟件中
Ubiquitous language (通用語言）
•將領域模型作爲語言的支柱
•領域模型包括類和主要操作的名稱
•領域模型儘量以文本爲主，穿插簡化圖爲說明
•不管是畫圖、寫文檔、寫代碼還是講話，都用的同一種術語
•語言是演進的
Layered architecture（分層架構）
* 用分層來隔離領域
* 層中的任何元素都僅依賴於本層其他元素，或其下層元素。
* 高內聚，低耦合
* 領域層應重點放在如何表達領域模型上，而不需要考慮自己的顯示和存儲問題
•用戶界面層
•向用戶顯示信息，解釋用戶命令
•應用層
•儘量簡單，不包含業務規則或知識
•只爲下層的領域對象分配任務，使他們協作
•領域層
•負責表達業務概念，業務狀態信息和業務規則
•基礎設施層
•上面各層提供通用的技術。比如持久化
Entity（實體）
•由標識定義的對象，而不是屬性
•整個生命週期都有聯繫性
•模型必須定義出“符合什麼條件纔算是相同的事物”
Value Ojbect（值對象）
•描述領域的某個方面，但本身沒有概念標識的對象
•關心它們是什麼，而不關心它們是誰
•值對象是不可變的，具體實現分爲共享和複製
Service（服務）
•領域操作（活動或者對象）
•定義能夠爲客戶做什麼，是動詞而不是名詞
•操作是無狀態的
•結果和參數應該是領域對象
•是否包含業務規則來確定是應用還是領域Service
Module（模塊）
•可以查看細節，而不會被整個模型淹沒
•可以觀察Module相互之間的關係，而不考慮細節
•將相同職責的對象放在一起
Aggregate（聚合）
•作爲數據修改的單元，一組相關對象的集合
•包括一個根（root）和一個邊界（boundary）
•根是Aggregate內一個特定的Entity
•Boundary定義了Aggregate內有哪些
•外部引用時，只可引用根；而邊界內部的對象之間可以相互引用
Factory（工廠）
•對象本身承擔大量的職責，讓複雜對象創建自身，會職責過載導致問題
•將職責交給客戶對象創建，會導致客戶必須瞭解對象內部規則，導致和領域類產生耦合
•Factory隱藏創建細節，通常和Aggregate有關
•當創建新對象未滿足固定規則時，Factory應拒絕創建對象
Repository（倉庫）
•同一類型的對象的集合
•具有複雜的查詢、添加和刪除對象功能
•只爲那些確實需要直接訪問的Aggreagte提供Repository，而不是所有對象都提供
Specfication（規格）
•計算結果是真或者假的函數，一般用動詞或形容詞
•用於驗證對象是否滿足特定的業務規則
•用於Repository查詢對象是否滿足要求
•用於創建對象時是否滿足需求
Bounded context（界限上下文）
•大型項目都會存在多個模型
•權利上的劃分和管理級別的不同也可能要求模型分開
•標記不同模型之間的邊界和關係
•邊界內部嚴格保持模型的一致性
•防止重複的概念和假同源
實現步驟：
•根據需求建立一個初步的領域模型，識別出一些明顯的領域概念以及它們的關聯
•分析程序功能，識別出應用層和領域層的職責
•識別Entity，Value Object，Service等
•找出Aggregate Root
•爲Aggregate寫Repository
•走查場景，分析領域模型是否解決業務需求
•考慮創建Entity，Value Object，Aggregate等是用Factory還是構造，又或者是IOC
•重構模型