DDD領域驅動設計筆記

摘自：dax.net陳晴陽博客

1.NLayerApp是經典的DDD架構

2.基礎結構層：包括兩方面內容，處理數據訪問的基礎結構層組件主要包含了倉儲的具體實現、Unit Of Work（PoEAA，Martin Fowler）的實現、NLayerApp的實體模型定義，以及爲單體測試作準備的Service Stubs（PoEAA，Martin Fowler）；Cross-Cutting的基礎結構層組件則主要包含了IoC（Inversion of Control）容器以及跟蹤應用程序執行過程的Trace工具。雖然這些都是基礎結構層的組件，但也包含了不少技術細節甚至是設計要點，就讓咱們一塊兒對這些內容作一個詳細的解讀。

3.關注點分離：分離關注點使得解決特定領域問題的代碼從業務邏輯中獨立出來，業務邏輯的代碼中再也不含有針對特定領域問題代碼的調用。

4.倉儲不是Data Object，也不單單是進行數據庫CRUD操做的Data Manager，它承擔瞭解耦領域模型和技術架構的重要職責。

5.依賴注入是維持領域模型純淨度的一大利器；另外一大利器是領域事件..net中微軟有一個輕量級的IoC框架Unity，支持構造器注入，屬性注入.IOC做用:將各層的對象以鬆耦合的方式組織在一塊兒，解耦，各層對象的調用徹底面向接口。當系統重構的時候，代碼的改寫量將大大減小。一般有調用者來建立被調用者的實例。建立被調用者的實例的工做由IOC容器來完成，而後注入調用者，所以也稱爲依賴注入。

6.領域層：包含了業務所涉及的領域對象（實體、值對象）、領域服務以及它們之間的關係。這部份內容的具體表現形式就是領域模型（Domain Model）。領域驅動設計提倡富領域模型，即儘可能將業務邏輯歸屬到領域對象上，實在沒法歸屬的部分則以領域服務的形式進行定義。表現層與應用層之間是經過DTO進行交互的，DTO是沒有行爲的POCO對象，目的只是爲了對領域對象進行數據封裝，實現層與層之間的數據傳遞。爲什麼不能直接將領域對象用於數據傳遞？由於領域對象更注重領域，而DTO更注重數據。不只如此，因爲「富領域模型」的特色，這樣作會直接將領域對象的行爲暴露給表現層

7.應用層：

數據傳輸對象DTO須要說明的幾點

　　1）DTO的設計須要面向客戶端（包括客戶端應用程序、與外部系統集成的Web Services等），客戶端的View Model須要什麼樣的數據，就設計什麼樣的DTO。應用層負責收發DTO數據，並根據DTO數據訪問領域模型中的實體，根據實體組裝DTO。ORM解決的是Domain Model與關係型數據庫之間的阻抗失衡，而DTO解決的是View Model與Domain Model之間的阻抗失衡
　　2）DTO應該是POCO，它不能依賴於任何技術框架
　　3）對於中小型系統，能夠考慮使用相似NLayerApp的Serialized Domain Entities方式，這能夠提升開發效率；但若是是大型系統，仍是建議使用DTO，有朋友會以爲每次根據View Model去設計DTO很耗時，但我以爲若是應用程序規模較大的時候，仍是作足功夫比較好，磨刀不誤砍柴工，這樣在從此作系統集成的時候也會方便一些。能夠考慮使用DSL與自動化代碼生成技術來解決DTO的設計問題
　　4）WCF產生的代理類Data Contracts就是一種DTO，若是專用微軟的技術，那麼也就與上述第二點不矛盾，Serialized Domain Entities能夠以Data Contracts的形式出如今客戶端程序中，必定程度上屏蔽了直接將Serialized Domain Entities用做DTO的負面影響

8.Specification是值對象，它是領域層的一部分，一樣也不會去關心持久化技術實現細節。規約是一種布爾斷言，它表述了給定的對象是否知足當前約定的語義。

 

 DDD領域驅動設計qq羣：463810724