三層架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

用戶(hù)界面層：

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

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

應(yīng)用層

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

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

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

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

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

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

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

對(duì)比三層分層與DDD分層

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

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

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

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

參考資料

《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)精簡(jiǎn)版》

總結(jié)

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

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