三層架構(gòu)

嚴(yán)格分層架構(gòu)模式的特點是上層只能訪問相鄰的下層，其他層次間的調(diào)用都不允許。三層架構(gòu)就是一種嚴(yán)格分層模式，它把職責(zé)劃分為界面展示、業(yè)務(wù)邏輯、數(shù)據(jù)訪問三層，還有一個業(yè)務(wù)實體，前面三層都要依賴它，所以它并不構(gòu)成一個層。

三層架構(gòu)的特點是一種面向過程的編程思想，特點如下：

a. 業(yè)務(wù)實體類中基本上只有屬性沒有方法。

b. 業(yè)務(wù)邏輯層的類基本上只有方法沒有屬性。

c. 將數(shù)據(jù)表結(jié)構(gòu)映射為業(yè)務(wù)實體類是一個慣用做法，以至于有人將其稱之為“傳統(tǒng)”。這樣的好處是只需要理解一套模型，能夠通過自動化工具從數(shù)據(jù)表直接生成業(yè)務(wù)實體，還能夠自然而然的通過自動化機制存儲與檢索業(yè)務(wù)實體。但對于復(fù)雜點的業(yè)務(wù)，這樣做就是絕大部分問題的根源。

d. 當(dāng)業(yè)務(wù)膨脹起來，需要劃分模塊的時候，我們有個常用的變形：提取一個服務(wù)層出來，用來組合模塊間的交互，還為業(yè)務(wù)邏輯層提供了一個防腐層，可以把記錄日志、驗證權(quán)限、處理異常等職責(zé)分配給服務(wù)層。

由于采用了嚴(yán)格分層模式，用戶界面層是絕對不能跨過業(yè)務(wù)邏輯層調(diào)用數(shù)據(jù)訪問層的，同理服務(wù)層也是不能調(diào)用數(shù)據(jù)訪問層。但是圖2都有四層了。

其實三層架構(gòu)還有個更準(zhǔn)確的名字----分層貧血領(lǐng)域模型架構(gòu)，前面名字中的領(lǐng)域模型指的是業(yè)務(wù)實體，貧血意思業(yè)務(wù)實體中沒有或很少方法。

三層架構(gòu)的反思

三層架構(gòu)的最大問題在于：實際應(yīng)用中人們喜歡把內(nèi)存模型和數(shù)據(jù)庫模型保持一致。三層架構(gòu)的大部分問題都是從這里衍生出來的。

數(shù)據(jù)庫模型的粒度如果很小，那么大量的表連接很快就會讓數(shù)據(jù)庫跑不動了。

如果數(shù)據(jù)庫模型的粒度如果很大(這是大部分項目的選擇)，代碼的質(zhì)量(重用性、穩(wěn)定性、擴展性)就很差。由于沒有從業(yè)務(wù)的角度去仔細(xì)定義每一個對象，每個人會根據(jù)自己的需要建立各種QueryModel或ViewModel，慢慢地類會多到想哭。

還有一些三層開發(fā)人員最終患上了數(shù)據(jù)庫癡迷癥，他堅信程序就應(yīng)該做個搬運工，其他的事情都應(yīng)該交給數(shù)據(jù)庫來完成，業(yè)務(wù)邏輯也應(yīng)該寫進存儲過程里面去。

三層分層到DDD分層的轉(zhuǎn)變過程

優(yōu)化三層結(jié)構(gòu)&重構(gòu)到面向?qū)ο蟮脑O(shè)計

由于目前的服務(wù)層職責(zé)是非常輕的，甚至有很多空殼的調(diào)用，所以平衡一下職責(zé)，把調(diào)用數(shù)據(jù)訪問層的職責(zé)從業(yè)務(wù)邏輯層提升到服務(wù)層，需要的數(shù)據(jù)通過參數(shù)傳遞給業(yè)務(wù)邏輯層。這樣，對于那些簡單到無業(yè)務(wù)邏輯的CRUD就不需要去訪問業(yè)務(wù)層了，直接調(diào)用數(shù)據(jù)訪問層。

結(jié)構(gòu)如圖3，我們看到業(yè)務(wù)邏輯與數(shù)據(jù)訪問層已經(jīng)沒有依賴關(guān)系了。

然后我們就可以把業(yè)務(wù)邏輯與業(yè)務(wù)實體移到一塊。

然后把屬于業(yè)務(wù)實體的邏輯遷移到實體類中。

圖4基本上就是圖3的各個層換了名字，并且UI可以訪問基礎(chǔ)設(shè)施層。而圖4與圖5的區(qū)別在于，圖4是基礎(chǔ)設(shè)施依賴領(lǐng)域?qū)?#xff0c;圖5是領(lǐng)域?qū)右蕾嚮A(chǔ)設(shè)施層。

用戶界面層：

原版----負(fù)責(zé)向用戶展現(xiàn)信息以及解釋用戶命令。

補充---- MVC中V和C都屬于UI層，V展現(xiàn)信息，C解析用戶命令。UI像地圖一樣把各個控制器關(guān)聯(lián)了起來。

應(yīng)用層

原版----很薄的一層，用來協(xié)調(diào)應(yīng)用的活動。它不包含業(yè)務(wù)邏輯。它不保留業(yè)務(wù)對象的狀態(tài)，但它保有應(yīng)用任務(wù)的進度狀態(tài)。

補充----協(xié)調(diào)應(yīng)用的活動這句話太抽象了，我充實一下它：從數(shù)據(jù)訪問中獲取領(lǐng)域?qū)ο?#xff0c;調(diào)用領(lǐng)域?qū)ο蟮姆椒ㄍ瓿扇蝿?wù)，然后再調(diào)用數(shù)據(jù)訪問代碼把領(lǐng)域?qū)ο蟮母淖兂志没Ｊ聞?wù)、權(quán)限檢查、記錄日志、處理異常的職責(zé)也歸它管。這點和前面三層的服務(wù)層的職責(zé)其實是一樣的。

領(lǐng)域?qū)?/p>

原版----本層包含關(guān)于領(lǐng)域的信息。這是業(yè)務(wù)軟件的核心所在。在這里保留業(yè)務(wù)對象的狀態(tài)，對業(yè)務(wù)對象和它們狀態(tài)的持久化被委托給了基礎(chǔ)設(shè)施層。

補充----業(yè)務(wù)對象的持久化工作我們已經(jīng)提升到應(yīng)用層了，一般情況下，這層最好不要涉及資源庫的調(diào)用，但是并不絕對。資源庫的抽象要么在領(lǐng)域?qū)又?#xff0c;要么提升到了“應(yīng)用程序框架”，領(lǐng)域?qū)邮遣粫蕾嚮A(chǔ)設(shè)施的。

基礎(chǔ)設(shè)施層

原版----本層作為其他層的支撐庫存在。它提供了層間的通信，實現(xiàn)對業(yè)務(wù)對象的持久化，包含對用戶界面層的支撐庫等作用。

對比三層分層與DDD分層

a. UI層技術(shù)基本一樣，一些比較智能的綁定可能無法進行了。

b. 服務(wù)層基本一樣。

d. 業(yè)務(wù)實體+業(yè)務(wù)邏輯 = 領(lǐng)域?qū)?/p>

e. 如果三層架構(gòu)不采用業(yè)務(wù)實體與數(shù)據(jù)表一致的做法，這層也是一樣。由于內(nèi)存結(jié)構(gòu)與數(shù)據(jù)表結(jié)構(gòu)之間存在阻抗失配，存取領(lǐng)域?qū)ο鬀]那么簡單。

參考資料

《領(lǐng)域驅(qū)動設(shè)計精簡版》

總結(jié)

以上是生活随笔為你收集整理的mysql 三层架构开发_从三层架构迈向领域驱动设计(转载)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。