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

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

　　過去系統分析和系統設計都是分離的，正如我們國家“系統分析師” 和“系統設計師” 兩種職稱考試一樣，這樣割裂的結果導致，需求分析的結果無法直接進行設計編程，而能夠進行編程運行的代碼卻扭曲需求，導致客戶運行軟件后才發現很多功能不是自己想要的，而且軟件不能快速跟隨需求變化。

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

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

UI+DataBase的兩層架構，這種面向數據庫的架構(上圖table module )沒有靈活性。

UI+Service+DataBase的多層SOA架構，這種服務+表模型的架構易使服務變得囊腫，難于維護拓展，伸縮性能差，見這里討論或Spring Web 應用的最大敗筆.

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

轉載于:https://www.cnblogs.com/cnlht/p/9495641.html

總結

以上是生活随笔為你收集整理的领域驱动设计(DDD:Domain-Driven Design)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。