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

出處：http://blog.csdn.net/johnstrive/article/details/16805121
說明：找了很多文章，看上去就像哲學論文一樣，並不能理解(看來還是要實踐中領悟了)。不過這篇文章讓我看懂一個大概的意思，所以記錄一下。

軟體開發要幹什麼：

反映真實世界要自動化的業務流程
解決現實問題

領域Domain

Domain特指軟體關注的領域
在不能充分了解業務領域的情況下是不可能做出一個好的軟體

領域建模

領域模型驅動設計
} 分層架構
} 實體
} 值物件
} 服務
} 模組
} 聚合
} 工廠
} 資源庫

分層架構：

} 將領域模型相關的程式碼集中到一個層中，把它從使用者介面、應用和基礎設施程式碼中分隔開來
} 釋放領域物件的顯示自己、儲存自己、管理應用任務等職責，讓它專注於展現領域模型
} 複雜的程式切分成層
} 層中採用內聚的設計
} 層僅依賴於它底下的那層

實體entity：有一類物件擁有唯一識別符號
} 能夠跨越系統的生命週期甚至能超越軟體系統的一系列的延續性和識別符號
} 這樣的物件稱為實體。
值物件-value Object
} 對某個物件是什麼不感興趣，只關心它擁有的屬性
} 用來描述領域的特殊方面、且沒有識別符號的一個物件，叫做值物件
} 能被簡單的建立和丟棄，生命週期中不會被持久化
} 值物件可以被共享，值物件應該不可變
服務-service（比webservice更細粒度服務描述）
} 領域中的一些動詞，代表了領域中的一個重要的行為，卻不屬於任何物件
◦ 服務執行的操作涉及一個領域概念，這個領域概念通常不屬於一個實體或者值物件
◦ 被執行的操作涉及到領域中的其他的物件
◦ 操作是無狀態的
} 服務物件不再擁有內建的狀態
} 服務物件擔當重要的協調功能
} 開發通用語言時，領域中的主要概念被引入到語言中，語言中的名詞很容易被對映成物件。
語言中對應那些名詞的動詞變成那些物件的行為。但是有些領域中的動作，它們是一些動詞，看上去卻不屬於任何物件。它們代表了領域中的一個重要的行為，所以不能忽略它們或者簡單的把它們合併到某個實體或者值物件中。給一個物件增加這樣的行為會破壞這個物件，讓它看上去擁有了本該屬於它的功能。

模組
} 將相關領域模型提煉分類，分而治之
} 將高關聯度的模型分組到一個模組以提供儘可能大的內聚（以能完整完成任務為準）
} 分層是水平劃分
} 模組是垂直劃分(Domain內部)

參考架構概述
} 領域驅動設計(DomainDriven Design)有一個官方的sample工程，名為DDDSample
} 官網：http://dddsample.sourceforge.net/
} 該工程給出了一種實踐領域驅動設計的參考架構
架構概述

詳細架構

架構詳解:Interfaces-介面層

} 該層包含與其他系統進行互動的介面與通訊設施，在多數應用裡
} 可能提供包括WebServices、RMI或Rest等在內的一種或多種通訊介面
} 該層主要由Facade、DTO和Assembler三類元件構成，三類元件均是典型的J2EE模式
DTO

} DTO- DataTransfer Object（資料傳輸物件），也常被稱作VO-ValueObject(值物件)
} DTO設計之初是為了將細粒度的領域物件包裝為粗粒度的資料結構，減少網路通訊並簡化呼叫介面
DTO 作用
} 減少網路流量
} 簡化遠端物件和遠端介面
} 傳輸更多的資料減少遠端呼叫次數
} 避免將領域狀態跨層次傳遞
} 由於同步和版本控制增加了複雜性
DTO 應用時序圖

Assembler

} DTO與領域物件之間的相互轉換工作多由Assembler承擔
} 因此Assembler幾乎總是同DTO一起出現。
Assembler 實現方案

Façade

} 實踐Facade的過程中最難把握的問題就是Facade的粒度問題。
} 傳統的Service均以實體為單位進行組織，而Facade應該具有更粗粒度的組織依據，較為合適的粒度依據有：
} 一個高度內聚的模組一個Facade
} 或者是一個“聚合”(特指領域驅動設計)一個Facade.
Facade 實現方案

Facade 應用時序圖

Service

} Service會與多種元件進行互動
} 這些元件包括：
◦ 其他的Service
◦ 領域物件
◦ Repository
◦ DAO
Service 應用時序圖

Domain-領域層

} Domain層是整個系統的核心層，該層維護一個使用物件導向技術實現的領域模型，幾乎全部的業務邏輯會在該層實現
} Domain層包含:
◦ Entity（實體）
◦ ValueObject(值物件)
◦ Domain Event（領域事件）
◦ Repository（倉儲）等
Infrastructure-基礎設施層

} 基礎設施層nfrastructure為Interfaces、Application和Domain三層提供支撐
} 所有與具體平臺、框架相關的實現會在Infrastructure中提供，避免三層特別是Domain層摻雜進這些實現，從而“汙染”領域模型
} Infrastructure中最常見的一類設施是物件持久化的具體實現
“傳統”架構-貧血領域模型

DDD && SOA
} DDD 領域模型驅動設計
} SOA 面向服務的架構