.NET應用架構設計—面向查詢的領域驅動設計實踐（調整傳統三層架構，外加維護型的業務開關）

閱讀目錄：

• 1.背景介紹
• 2.在業務層中加入核心領域模型（引入DomainModel，讓邏輯、數據有家可歸，變成一個完整的業務對象）
• 3.統一協調層Application Layer（加入協調層來轉換DomianModel）
• 4.從數據扁平結構轉換成OO體系結構（使用OO豐富代碼結構）
• 5.DomainModel中的內容（帶開關的Specification、SOA化的Specification）
• 6.模式、重構、單元測試在領域模型中的運用

1.背景介紹

因爲時間關係廢話很少扯了，直奔主題，對領域驅動設計不是太瞭解的朋友請先熟悉相關主題或參考本人如下兩篇文章：

.NET領域驅動設計—初嘗(疑問、模式、原則、工具、過程、框架、實踐)，這篇文章對領域驅動設計的基本精神詳細分析；

.NET領域驅動設計—實踐(穿過迷霧走向光明) ，這篇文章對領域驅動設計的一個基本實踐，記錄下了實踐過程、建模的技巧等內容；

DomainModel是由不少細粒度的Object組成，按照以往的教訓（將Object行爲、數據肢解，獲得一個殘缺的Object），如今咱們將邏輯行爲和數據綁定在一塊兒，造成了一個豐富的領域模型，這也是面向對象設計原則之一；想了解更多關於實現面向對象的技巧請參考【《實現模式》做者：Kent Beck】一書；

可是這樣又帶來了因爲充血型DDD模型會給面向大規模查詢的業務模塊帶來必定的性能開銷，試想一個OrderManager對象，若是咱們須要獲取在某個條件範圍類的全部Order會給OrderManager帶來不少性能、邏輯上的複雜度；根據DDD.CQRS架構，得知將DomainModel中的查詢邏輯單獨剝離出去，讓Command端很乾淨的處理聚合的寫邏輯，在Query端也很直接的處理查詢邏輯；

這樣設計以後會有一個很尷尬的狀況，在Query端的DomainModel不被關注了，由於Query的邏輯有簡單有複雜，大型站點會有不少複雜的查詢邏輯還會有不少的業務開關，作過維護的朋友應該知道新功能上線須要有switch的控制，這是爲了安全起見吧；可是簡單的業務邏輯就會被咱們下意識的認爲不須要使用完整的DomainModel結構，仍是使用傳統的分層架構上層依賴下層，Business Layer直接依賴DataAccess Layer，其實這個時候Business Object已經不在是遵循「單一職責」原則了，這樣時間一長又慢慢的回到了之前肢解Object的困境；

這篇文章是講解如何在Query端實踐DDD，如何運用DDD的強項來解決複雜業務邏輯的實現，尤爲是複雜的業務邏輯須要開關控制的時候其實更須要DomainModel來完成；

2.在業務層中加入核心領域模型（引入DomainModel，讓邏輯、數據有家可歸，變成一個完整的業務對象）

因爲咱們缺少領域模型，因此致使咱們的業務邏輯、規則隨波逐流，無家可歸，時間久了就搞不清到底這塊業務邏輯是哪裏的；咱們現有的Domain Model是一個數據映射對象用來傳遞數據用的，嚴格意義是一個DTO對象，大部分的項目都將DTO命名爲DomainModel可是其實裏面沒有任何的行爲、方法，只是一個純粹的數據傳輸用的容器，因此稱不上DomainModel；

因此咱們首先要作的就是加入DomainModel，而後逐漸將邏輯搬移到DomainModel中來，在進行逐步的重構、單元測試，讓其成爲一個能夠測試的具備必定核心價值的可重用的DomainModel；

3.統一協調層Application Layer（加入協調層來轉換DomainModel）

咱們的Service沒有Application Layer  也稱協調層，專門用來組裝業務處理環節的統一調度中心，它並不是只是一個簡單的靜態類；傳統三層中沒有應用層的概念或者說應用層的概念沒扭曲了，或者並無發揮其的核心做用；咱們須要加入應用層來協調DomainModel的工做；

4.從數據扁平結構轉換成OO體系結構（使用OO豐富代碼結構）

當咱們使用DTO對象成功將數據從數據源獲取以後，就須要一個對象化的過程，將扁平化的數據實體轉換成豐滿的領域模型，這個時候全部的領域規則將起做用；

5.DomainModel中的內容（帶開關的Specification、SOA化的Specification）

1.實體:

簡單理解爲OO對象，能夠獨立存在也能夠聚合在某個領域實體下，若是聚合在某個實體下那麼只能經過父級實體進行一系列的訪問；

2.工廠:

對實體進行有相關約定的建立，這其中包括各類驗證、約束、開關等等前提條件。注意：建立實體不像建立數據DTO那麼簡單；

3.規約、規約工廠:

對業務規則進行對象化，將本來淹沒在雜亂無章代碼中的核心業務規則提取出來統一管理；這能夠很好的像規則配置化（專業稱：規則外掛）；注意：這能夠和咱們的業務開關進行合併；最值得驚喜的是能夠經過規約工廠來實現面向SOA的規約；

4.領域事件（擴展）:

監控、觀察等等非侵入式的獲取實體在業務處理當中的狀態數據，如：發送一封郵件、記錄一條LOG，可是這種代碼嚴禁寫入業務邏輯層包括分層架構中的任何一個層面，它必須是在一個可有可無的宿主中進行，相似管道模型的Module；

5.面向特定業務開關:

因爲咱們每次添加或修改業務邏輯都會加入相應的開關控制，若是這個開關是和業務邏輯相關的那麼就能夠很巧妙的和規約合併設計；

6.模式、重構、單元測試在領域模型中的運用

設計模式的運用：經過運用DDD就能夠方便的對Domain Model進行設計模式的強粒度運用；

重構的運用：對領域模型進行重構就不須要考慮業務邏輯會影響到其餘層面；

單元測試的運用：能夠獨立對領域模型進行測試，包括細粒度的接口抽取都會很方便；

 

總結：因爲時間關係文中都是精簡的介紹，具體的理解能夠參考我上傳的代碼示例:http://files.cnblogs.com/wangiqngpei557/3WDDDDemo.zip

 

做者：王清培

出處：http://www.cnblogs.com/wangiqngpei557/

本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面