.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://wangqingpei557.blog.51cto.com/

本文版權歸作者和51CTO共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。