軟件開發要干什么：

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

領域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? 面向服務的架構

http://blog.csdn.net/johnstrive/article/details/16805121

總結

以上是生活随笔為你收集整理的领域模型驱动设计（Domain Driven Design）入门概述的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。