概述
過去系統(tǒng)分析和系統(tǒng)設計都是分離的废菱，正如我們國家“系統(tǒng)分析師” 和“系統(tǒng)設計師” 兩種職稱考試一樣搀继，這樣割裂的結果導致吟策，需求分析的結果無法直接進行設計編程驶冒，而能夠進行編程運行的代碼卻扭曲需求苟翻，導致客戶運行軟件后才發(fā)現(xiàn)很多功能不是自己想要的搭伤，而且軟件不能快速跟隨需求變化。
DDD則打破了這種隔閡袜瞬，提出了領域模型概念，統(tǒng)一了分析和設計編程身堡，使得軟件能夠更靈活快速跟隨需求變化邓尤。見下面DDD與傳統(tǒng)CRUD或過程腳本或者面向數(shù)據(jù)表等在開發(fā)效率上比較：
服務器后端發(fā)展三個階段：
- UI+DataBase的兩層架構，這種面向數(shù)據(jù)庫的架構(上圖table module )沒有靈活性贴谎。
- UI+Service+DataBase的多層SOA架構汞扎，這種服務+表模型的架構易使服務變得囊腫，難于維護拓展擅这，伸縮性能差澈魄，見這里討論或Spring Web 應用的最大敗筆.
- DDD+SOA的事件驅動的CQRS讀寫分離架構，應付復雜業(yè)務邏輯仲翎，以聚合模型替代數(shù)據(jù)表模型痹扇，以并發(fā)的事件驅動替代串聯(lián)的消息驅動。真正實現(xiàn)以業(yè)務實體為核心的靈活拓展溯香。
DDD革命性在于：領域模型準確反映了業(yè)務語言鲫构，而傳統(tǒng)J2EE或Spring+Hibernate等事務性編程模型只關心數(shù)據(jù)，這些數(shù)據(jù)對象除了簡單setter/getter方法外玫坛，沒有任何業(yè)務方法结笨，被比喻成失血模型，那么領域模型這種帶有業(yè)務方法的充血模型到底好在哪里湿镀？
以比賽Match為案例炕吸，比賽有“開始”和“結束”等業(yè)務行為，但是傳統(tǒng)經(jīng)典的方式是將“開始”和“結束”行為放在比賽的服務Service中勉痴，而不是放在比賽對象本身之中赫模。我們不能因為用了計算機，用了數(shù)據(jù)庫蚀腿，用了框架嘴瓤，業(yè)務模型反而被技術框架給綁架，就像人雖然是由母親生的莉钙，但是人的吃喝拉撒母親不能替代廓脆，更不能以母愛名義肢解人的正常職責行為，如果是這樣磁玉，這個人就是被母愛綁架了停忿。
DDD最大的好處是：接觸到需求第一步就是考慮領域模型，而不是將其切割成數(shù)據(jù)和行為蚊伞，然后數(shù)據(jù)用數(shù)據(jù)庫實現(xiàn)席赂，行為使用服務實現(xiàn)吮铭，最后造成需求的首肢分離。DDD讓你首先考慮的是業(yè)務語言颅停，而不是數(shù)據(jù)谓晌。重點不同導致編程世界觀不同。
DDD是解決復雜中大型軟件的一套行之有效方式癞揉，在國外已經(jīng)成為主流纸肉。DDD認為很多原因造成軟件的復雜性，我們不可能避免這些復雜性喊熟，能做的是對復雜的問題進行控制柏肪。而一個好的領域模型是控制復雜問題的關鍵。領域模型的價值在于提供一種通用的語言芥牌，使得領域專家和軟件技術人員聯(lián)系在一起烦味，溝通無歧義。
DDD在軟件生產(chǎn)流程中定位i如下圖壁拉，DDD落地實現(xiàn)離不開in-memory緩存谬俄、 CQRS、 DCI弃理、 EDA或Event Source幾大大相關領域凤瘦。
