.NET應(yīng)用架構(gòu)設(shè)計—面向查詢的領(lǐng)域驅(qū)動設(shè)計實踐（調(diào)整傳統(tǒng)三層架構(gòu)，外加維護型的業(yè)務(wù)開關(guān)）

閱讀目錄：

?

• 1.背景介紹
• 2.在業(yè)務(wù)層中加入核心領(lǐng)域模型（引入DomainModel，讓邏輯、數(shù)據(jù)有家可歸，變成一個完整的業(yè)務(wù)對象）
• 3.統(tǒng)一協(xié)調(diào)層Application Layer（加入?yún)f(xié)調(diào)層來轉(zhuǎn)換DomianModel）
• 4.從數(shù)據(jù)扁平結(jié)構(gòu)轉(zhuǎn)換成OO體系結(jié)構(gòu)（使用OO豐富代碼結(jié)構(gòu)）
• 5.DomainModel中的內(nèi)容（帶開關(guān)的Specification、SOA化的Specification）
• 6.模式、重構(gòu)、單元測試在領(lǐng)域模型中的運用

?

1.背景介紹

?

由于時間關(guān)系廢話不多扯了，直奔主題，對領(lǐng)域驅(qū)動設(shè)計不是太了解的朋友請先熟悉相關(guān)主題或參考本人以下兩篇文章：

?

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

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

?

DomainModel是由很多細(xì)粒度的Object組成，按照以往的教訓(xùn)（將Object行為、數(shù)據(jù)肢解，得到一個殘缺的Object），現(xiàn)在我們將邏輯行為和數(shù)據(jù)綁定在一起，形成了一個豐富的領(lǐng)域模型，這也是面向?qū)ο笤O(shè)計原則之一；想了解更多關(guān)于實現(xiàn)面向?qū)ο蟮募记烧垍⒖? 【《實現(xiàn)模式》作者：Kent Beck】 一書；

?

但是這樣又帶來了由于充血型DDD模型會給面向大規(guī)模查詢的業(yè)務(wù)模塊帶來一定的性能開銷，試想一個OrderManager對象，如果我們需要獲取在某個條件范圍類的所有Order會給OrderManager帶來很多性能、邏輯上的復(fù)雜度；根據(jù)DDD.CQRS架構(gòu)，得知將DomainModel中的查詢邏輯單獨剝離出去，讓Command端很干凈的處理聚合的寫邏輯，在Query端也很直接的處理查詢邏輯；

?

這樣設(shè)計之后會有一個很尷尬的情況，在Query端的DomainModel不被關(guān)注了，因為Query的邏輯有簡單有復(fù)雜，大型站點會有很多復(fù)雜的查詢邏輯還會有很多的業(yè)務(wù)開關(guān)，做過維護的朋友應(yīng)該知道新功能上線需要有switch的控制，這是為了安全起見吧；但是簡單的業(yè)務(wù)邏輯就會被我們下意識的認(rèn)為不需要使用完整的DomainModel結(jié)構(gòu)，還是使用傳統(tǒng)的分層架構(gòu)上層依賴下層，Business Layer直接依賴DataAccess Layer，其實這個時候Business Object已經(jīng)不在是遵循“單一職責(zé)”原則了，這樣時間一長又慢慢的回到了以前肢解Object的困境；

?

這篇文章是講解如何在Query端實踐DDD，如何運用DDD的強項來解決復(fù)雜業(yè)務(wù)邏輯的實現(xiàn)，尤其是復(fù)雜的業(yè)務(wù)邏輯需要開關(guān)控制的時候其實更需要DomainModel來完成；

?

2.在業(yè)務(wù)層中加入核心領(lǐng)域模型（引入DomainModel，讓邏輯、數(shù)據(jù)有家可歸，變成一個完整的業(yè)務(wù)對象）

?

由于我們?nèi)狈︻I(lǐng)域模型，所以導(dǎo)致我們的業(yè)務(wù)邏輯、規(guī)則隨波逐流，無家可歸，時間久了就搞不清到底這塊業(yè)務(wù)邏輯是哪里的； 我們現(xiàn)有的Domain Model是一個數(shù)據(jù)映射對象用來傳遞數(shù)據(jù)用的，嚴(yán)格意義是一個DTO對象，大部分的項目都將DTO命名為DomainModel但是其實里面沒有任何的行為、方法，只是一個純粹的數(shù)據(jù)傳輸用的容器，所以稱不上DomainModel；

?

所以我們首先要做的就是加入DomainModel，然后逐漸將邏輯搬移到DomainModel中來，在進行逐步的重構(gòu)、單元測試，讓其成為一個可以測試的具有一定核心價值的可重用的DomainModel；

?

3.統(tǒng)一協(xié)調(diào)層Application Layer（加入?yún)f(xié)調(diào)層來轉(zhuǎn)換DomainModel）

?

我們的Service沒有Application Layer? 也稱協(xié)調(diào)層，專門用來組裝業(yè)務(wù)處理環(huán)節(jié)的統(tǒng)一調(diào)度中心，它并非只是一個簡單的靜態(tài)類；傳統(tǒng)三層中沒有應(yīng)用層的概念或者說應(yīng)用層的概念沒扭曲了，或者并沒有發(fā)揮其的核心作用；我們需要加入應(yīng)用層來協(xié)調(diào)DomainModel的工作；

?

4.從數(shù)據(jù)扁平結(jié)構(gòu)轉(zhuǎn)換成OO體系結(jié)構(gòu)（使用OO豐富代碼結(jié)構(gòu)）

?

當(dāng)我們使用DTO對象成功將數(shù)據(jù)從數(shù)據(jù)源獲取之后，就需要一個對象化的過程，將扁平化的數(shù)據(jù)實體轉(zhuǎn)換成豐滿的領(lǐng)域模型，這個時候所有的領(lǐng)域規(guī)則將起作用；

?

5.DomainModel中的內(nèi)容（帶開關(guān)的Specification、SOA化的Specification）

?

1.實體:

?

簡單理解為OO對象，可以獨立存在也可以聚合在某個領(lǐng)域?qū)嶓w下，如果聚合在某個實體下那么只能通過父級實體進行一系列的訪問；

?

2.工廠:

?

對實體進行有相關(guān)約定的創(chuàng)建，這其中包括各種驗證、約束、開關(guān)等等前提條件。注意：創(chuàng)建實體不像創(chuàng)建數(shù)據(jù)DTO那么簡單；

?

3.規(guī)約、規(guī)約工廠:

?

對業(yè)務(wù)規(guī)則進行對象化，將原本淹沒在雜亂無章代碼中的核心業(yè)務(wù)規(guī)則提取出來統(tǒng)一管理；這可以很好的像規(guī)則配置化（專業(yè)稱：規(guī)則外掛）；注意：這可以和我們的業(yè)務(wù)開關(guān)進行合并；最值得驚喜的是可以通過規(guī)約工廠來實現(xiàn)面向SOA的規(guī)約；

?

4.領(lǐng)域事件（擴展）:

?

監(jiān)控、觀察等等非侵入式的獲取實體在業(yè)務(wù)處理當(dāng)中的狀態(tài)數(shù)據(jù)，如：發(fā)送一封郵件、記錄一條LOG，但是這種代碼嚴(yán)禁寫入業(yè)務(wù)邏輯層包括分層架構(gòu)中的任何一個層面，它必須是在一個無關(guān)緊要的宿主中進行，類似管道模型的Module；

?

5.面向特定業(yè)務(wù)開關(guān):

?

由于我們每次添加或修改業(yè)務(wù)邏輯都會加入相應(yīng)的開關(guān)控制，如果這個開關(guān)是和業(yè)務(wù)邏輯相關(guān)的那么就可以很巧妙的和規(guī)約合并設(shè)計；

?

6.模式、重構(gòu)、單元測試在領(lǐng)域模型中的運用

?

設(shè)計模式的運用：通過運用DDD就可以方便的對Domain Model進行設(shè)計模式的強粒度運用；

?

重構(gòu)的運用：對領(lǐng)域模型進行重構(gòu)就不需要考慮業(yè)務(wù)邏輯會影響到其他層面；

?

單元測試的運用：可以獨立對領(lǐng)域模型進行測試，包括細(xì)粒度的接口抽取都會很方便；

?

?

?

總結(jié)：由于時間關(guān)系文中都是精簡的介紹，具體的理解可以參考我上傳的代碼示例: http://files.cnblogs.com/wangiqngpei557/3WDDDDemo.zip

?

?

面向查詢的領(lǐng)域驅(qū)動設(shè)計實踐