軟件開發要干什么：
反映真實世界要自動化的業務流程
解決現實問題
領域Domain
Domain特指軟件關注的領域
在不能充分了解業務領域的情況下是不可能做出一個好的軟件
領域建模
領域模型驅動設計
- 分層架構
- 實體
- 值對象
- 服務
- 模塊
- 聚合
- 工廠
- 資源庫
分層架構：
- 將領域模型相關的代碼集中到一個層中，把它從用戶界面、應用和基礎設施代碼中分隔開來
- 釋放領域對象的顯示自己、保存自己、管理應用任務等職責，讓它專注於展現領域模型
- 復雜的程序切分成層
- 層中采用內聚的設計
- 層僅依賴於它底下的那層
實體entity：有一類對象擁有唯一標識符
- 能夠跨越系統的生命周期甚至能超越軟件系統的一系列的延續性和標識符
- 這樣的對象稱為實體。
- 對某個對象是什么不感興趣，只關心它擁有的屬性
- 用來描述領域的特殊方面、且沒有標識符的一個對象，叫做值對象
- 能被簡單的創建和丟棄，生命周期中不會被持久化
- 值對象可以被共享，值對象應該不可變
- 領域中的一些動詞，代表了領域中的一個重要的行為，卻不屬於任何對象
- 服務執行的操作涉及一個領域概念，這個領域概念通常不屬於一個實體或者值對象
- 被執行的操作涉及到領域中的其他的對象
- 操作是無狀態的
- 服務對象不再擁有內置的狀態
- 服務對象擔當重要的協調功能
- 開發通用語言時，領域中的主要概念被引入到語言中，語言中的名詞很容易被映射成對象。
模塊
- 將相關領域模型提煉分類，分而治之
- 將高關聯度的模型分組到一個模塊以提供盡可能大的內聚（以能完整完成任務為准）
- 分層是水平划分
- 模塊是垂直划分(Domain內部)
參考架構概述
- 領域驅動設計(DomainDriven Design)有一個官方的sample工程，名為DDDSample
- 官網：http://dddsample.sourceforge.net/
- 該工程給出了一種實踐領域驅動設計的參考架構
架構概述
詳細架構
架構詳解:Interfaces-接口層
- 該層包含與其他系統進行交互的接口與通信設施，在多數應用里
- 可能提供包括WebServices、RMI或Rest等在內的一種或多種通信接口
- 該層主要由Facade、DTO和Assembler三類組件構成，三類組件均是典型的J2EE模式
- DTO- DataTransfer Object（數據傳輸對象），也常被稱作VO-ValueObject(值對象)
- DTO設計之初是為了將細粒度的領域對象包裝為粗粒度的數據結構，減少網絡通信並簡化調用接口
DTO 作用
- 減少網絡流量
- 簡化遠程對象和遠程接口
- 傳輸更多的數據減少遠程調用次數
- 避免將領域狀態跨層次傳遞
- 由於同步和版本控制增加了復雜性
Assembler
- DTO與領域對象之間的相互轉換工作多由Assembler承擔
- 因此Assembler幾乎總是同DTO一起出現。
Façade
- 實踐Facade的過程中最難把握的問題就是Facade的粒度問題。
- 傳統的Service均以實體為單位進行組織，而Facade應該具有更粗粒度的組織依據，較為合適的粒度依據有：
- 一個高度內聚的模塊一個Facade
- 或者是一個“聚合”(特指領域驅動設計)一個Facade.
Facade 應用時序圖
Service
Service會與多種組件進行交互，這些組件包括：
- 其他的Service
- 領域對象
- Repository
- DAO
Domain-領域層
} Domain層是整個系統的核心層，該層維護一個使用面向對象技術實現的領域模型，幾乎全部的業務邏輯會在該層實現
} Domain層包含:
◦ Entity（實體）
◦ ValueObject(值對象)
◦ Domain Event（領域事件）
◦ Repository（倉儲）等
Infrastructure-基礎設施層
- 基礎設施層nfrastructure為Interfaces、Application和Domain三層提供支撐
- 所有與具體平台、框架相關的實現會在Infrastructure中提供，避免三層特別是Domain層摻雜進這些實現，從而“污染”領域模型
- Infrastructure中最常見的一類設施是對象持久化的具體實現
DDD && SOA
- DDD 領域模型驅動設計
- SOA 面向服務的架構