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幾大大相關領域。
