領域驅動設計(DDD:Domain-Driven Design)

領域驅動設計(DDD:Domain-Driven Design)

　　Eric Evans的「Domain-Driven Design領域驅動設計」簡稱DDD，Evans DDD是一套綜合軟件系統分析和設計的面向對象建模方法，本站Jdon.com是國內公開最先討論DDD網站之一，可訂閱 DDD專題。初學者學習DDD可從研究本站Jdon框架的DDD應用源碼開始， 戳這裏開始。

　　過去系統分析和系統設計都是分離的，正如咱們國家「系統分析師」 和「系統設計師」 兩種職稱考試同樣，這樣割裂的結果致使，需求分析的結果沒法直接進行設計編程，而可以進行編程運行的代碼卻扭曲需求，致使客戶運行軟件後才發現不少功能不是本身想要的，並且軟件不能快速跟隨需求變化。

　　DDD則打破了這種隔閡，提出了領域模型概念，統一了分析和設計編程，使得軟件可以更靈活快速跟隨需求變化。見下面DDD與傳統CRUD或過程腳本或者面向數據表等在開發效率上比較：

　　服務器後端發展三個階段：

1. UI+DataBase的兩層架構，這種面向數據庫的架構(上圖table module )沒有靈活性。
2. UI+Service+DataBase的多層SOA架構，這種服務+表模型的架構易使服務變得囊腫，難於維護拓展，伸縮性能差，見這裏討論或Spring Web 應用的最大敗筆.
3. DDD+SOA的事件驅動的CQRS讀寫分離架構，應付複雜業務邏輯，以聚合模型替代數據表模型，以併發的事件驅動替代串聯的消息驅動。真正實現以業務實體爲核心的靈活拓展。

　　DDD革命性在於：領域模型準確反映了業務語言，而傳統J2EE或Spring+Hibernate等事務性編程模型只關心數據，這些數據對象除了簡單setter/getter方法外，沒有任何業務方法，被比喻成失血模型，那麼領域模型這種帶有業務方法的充血模型到底好在哪裏？

　　以比賽Match爲案例，比賽有「開始」和「結束」等業務行爲，可是傳統經典的方式是將「開始」和「結束」行爲放在比賽的服務Service中，而不是放在比賽對象自己之中。咱們不能由於用了計算機，用了數據庫，用了框架，業務模型反而被技術框架給綁架，就像人雖然是由母親生的，可是人的吃喝拉撒母親不能替代，更不能以母愛名義肢解人的正常職責行爲，若是是這樣，這我的就是被母愛綁架了。

　　提倡充血模型，實際就是讓過去被肢解被黑crack的業務模型迴歸正常，固然這也會被一些先入爲主或被洗過腦的程序員當作反而不正常，這更是極大可悲之處。看到領域模型代碼，就看到業務需求，沒有翻譯沒有轉換，保證軟件真正實現「拷貝不走樣」。

　　DDD最大的好處是：接觸到需求第一步就是考慮領域模型，而不是將其切割成數據和行爲，而後數據用數據庫實現，行爲使用服務實現，最後形成需求的首肢分離。DDD讓你首先考慮的是業務語言，而不是數據。重點不一樣致使編程世界觀不一樣。

　　DDD是解決複雜中大型軟件的一套行之有效方式，在國外已經成爲主流。DDD認爲不少緣由形成軟件的複雜性，咱們不可能避免這些複雜性，能作的是對複雜的問題進行控制。而一個好的領域模型是控制複雜問題的關鍵。領域模型的價值在於提供一種通用的語言，使得領域專家和軟件技術人員聯繫在一塊兒，溝通無歧義。

　　DDD在軟件生產流程中定位i以下圖，DDD落地實現離不開in-memory緩存、 CQRS、 DCI、 EDA或Event Source幾大大相關領域。

From：http://www.jdon.com/ddd.html