回到目錄
概念中的ＤＤＤ
ＤＤＤ： 領域驅動設計，它是對面向對象的的分析和設計（ＯＯＡＤ，Object Orient Analysis Design）的一個補充，對技術框架進行了分層規划，同時對每個類進行了策略和類型划分。領域模型是領域驅動的核心 ，采用ＤＤＤ的設計思想，業務邏輯不再集中在幾個大型的類上，而是在大量相對小的領域對象上，這些類具有自己的狀態和行為，每個類都是完成的獨立的，並與現實領域的業務對象形成一種映射。基於ＤＤＤ的架構設計，保證了系統的可維護性，擴展性和敏捷性，在處理復雜業務邏輯方面有着明顯的優勢！
編程世界觀的改變
以下信息是從http://www.jdon.com/ddd.html上拷貝的，寫的很好，這確實是一種編程世界觀的改變，而傳傳統編程觀念完全不同
過去需求分析和系統設計都是分離的，正如我們國家“系統分析師” 和“系統設計師” 兩種職稱考試一樣，這樣割裂的結果導致，需求分析的結果無法直接進行設計編程，而能夠進行編程運行的代碼卻扭曲需求，導致客戶運行軟件后才發現很多功能不是自己想要的，而且軟件不能快速跟隨需求變化。
DDD則打破了這種隔閡，提出了領域模型概念，統一了分析和設計編程，使得軟件能夠更靈活快速跟隨需求變化。
DDD革命性在於：領域模型准確反映了業務語言，而傳統的分層架構只關心數據， 這些數據對象除了簡單讀、寫操作外，沒有任何業務方法，被比喻成失血模型，那么領域模型這種帶有業務方法的充血模型到底好在哪里？
看到領域模型代碼，就看到業務需求，沒有翻譯沒有轉換，保證軟件真正實現“拷貝不走樣”。
DDD最大的好處是：接觸到需求第一步就是考慮領域模型，而不是將其切割成數據和行為，然后數據用數據庫實現，行為使用服務實現，最后造成需求的首肢分離。DDD讓你首先考慮的是業務語言，而不是數據。重點不同導致編程世界觀不同。
ＤＤＤ的特點
- 分層架構
- 成熟，清晰的分層架構
- 領域對象與世界的業務映射
- 明確的職責划分
- 復用性
- 領域對象是核心
- 領域對象復用：完整的業務對象描述
- 設計利用：設計基於領域對象而非基於數據庫的
- 適用場合
- 具備復雜業務邏輯的軟件開發
- 對設計和開發人員要求較高
- 不適合普通的ＣＵＲＤ操作
- 系統的維護性與擴展性較高
對於ＤＤＤ系統架構的分層
不使用ＤＤＤ思想進行系統設計時，一般會分為３層，如數據層，業務層和表現層，而使用ＤＤＤ這后，分層的方式發生了一些改變，先來看一下
- 表現層：也叫ＷＥＢ層，ＵＩ層，一般體現出來的是頁面的布局，可以用web mvc,web form,win form等去實現
- 應用層：用來協調應用活動，它不包含業務邏輯，它不保留業務對象的狀態，但它保存應用任務的進度狀態
- 領域層：包含領域信息，這是業務軟件的核心，它保留業務對象的狀態，對業務對象和它們狀態的持久化工作委托給基礎設施層
- 基礎設施層：是其它層的基礎，實現對業務對象的持久化，還對ＷＥＢ層可以引用本層
ＤＤＤ中的幾個核心對象
Entities:這不是簡單的poco實體，而是具備了業務邏輯的實體
Factories:工廠類，用來生產對象
Respositories:持久化,它本身就是DAO (Data Access Objects) 數據訪問對象
Services：服務層，為上層提供了操作的接口，負責對象領域對象進行調試和封裝，同時提供了各種形式的服務
ＯＫ，今天這講先說到這里，只是概念，要求我們去理解它，事實上，這種理解確實有別於之前的架構思想，它是一種與傳統方式截然不同的，需要我們用心去體會！
感謝您的閱讀
相關文章
DDD~microsoft NLayerApp項目中的層次結構圖