公司裡面敏捷專案要講ddd領域驅動設計，加緊學習了一下，找了一些資料研究。
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幾大大相關領域。
參考：
DDD（領域驅動設計）
domain 領域 driven 驅動 design 設計 由eric evans最先提出，目的是對軟體所涉及到的領域進行建模，以應對系統規模過大時引起的軟體複雜性的問題。整個過程大概是這樣 開發團隊和領域專家一起通過 通用語言 ubiquitous language 去理解和消化領域知識，從領域知...
DDD領域驅動設計
極客時間學習筆記 為什麼微服務設計的時候需要ddd？1 軟體架構模式演進的三個階段 第一階段是單機架構 第二階段是集中式架構 第三階段是分布式微服務架構 2 在單機和集中式架構這兩種模式下，軟體無法快速響應需求和業務的迅速變化，最終錯失發展良機。3 微服務拆分困境產生的根本原因就是不知道業務或者微服...
領域驅動設計（DDD）
ddd是一種軟體設計方法，簡單來說，就是先建立一套業務領域的軟體模型，然後以此模型為核心進行軟體設計和開發。ddd主要有以下幾個優點 1 ddd會建立一套模型，即領域模型，這個模型是業務領域知識的濃縮，可以避免領域知識的流失。2 ddd和物件導向程式設計高度契合，領域模型將一比一直接反映到 中，由此...