【架構(gòu)設(shè)計】你的應(yīng)用該如何分層呢?
前言
最近review公司的代碼,發(fā)現(xiàn)現(xiàn)在整個代碼層級十分混亂,一個service類的長度甚至達(dá)到了5000多行。而且各種分層模型DTO、VO亂用, 最終出現(xiàn)邏輯不清晰、各模塊相互依賴、代碼擴(kuò)展性差、改動一處就牽一發(fā)而動全身等問題。
我們在吸取了阿里巴巴的分層規(guī)范以及網(wǎng)上的一些經(jīng)驗(yàn)后,重新梳理總結(jié)了屬于我們項(xiàng)目的分層規(guī)范。
三層架構(gòu)VS四層架構(gòu)
我們公司原來的分層采用的是傳統(tǒng)的三層架構(gòu),比如在構(gòu)建項(xiàng)目的時候,我們通常會建立三個目錄:Web、Service 和 Dao,它們分別對應(yīng)了表現(xiàn)層、邏輯層還有數(shù)據(jù)訪問層。
這樣導(dǎo)致一個很大的問題,隨著業(yè)務(wù)越來越復(fù)雜,邏輯層也就是service層越來越龐大,所以出現(xiàn)了前面說的5000多行的類,可想而知維護(hù)成本有多大。
參照阿里發(fā)布的《阿里巴巴 Java 開發(fā)手冊 v1.4.0(詳盡版)》,我們可以將原先的三層架構(gòu)細(xì)化成下面的樣子:
- 終端顯示層:各端模板渲染并執(zhí)行顯示的層。當(dāng)前主要是 Velocity 渲染,JS 渲染, JSP 渲染,移動端展示等。
- 開放接口層:將Service 層方法封裝成開放接口,同時進(jìn)行網(wǎng)關(guān)安全控制和流量控制等。
- Web 層:主要是對訪問控制進(jìn)行轉(zhuǎn)發(fā),各類基本參數(shù)校驗(yàn),或者不復(fù)用的業(yè)務(wù)簡單處理等。
- Service 層:業(yè)務(wù)邏輯層。
- Manager 層:通用業(yè)務(wù)處理層。主要實(shí)現(xiàn)下面的功能,1) 對第三方平臺封裝的層,預(yù)處理返回結(jié)果及轉(zhuǎn)化異常信息,適配上層接口。2) 對 Service 層通用能力的下沉,如緩存方案、中間件通用處理。3) 與 DAO 層交互,對多個 DAO 的組合復(fù)用。
- DAO 層:數(shù)據(jù)訪問層,與底層 MySQL、Oracle、Hbase 等進(jìn)行數(shù)據(jù)交互。
- 外部接口或第三方平臺:包括其它部門RPC 開放接口,基礎(chǔ)平臺,其它公司的 HTTP 接口。
在這個分層架構(gòu)中主要增加了 Manager 層,它可以將Service層中的一些通用能力比如操作緩存、消息隊列的操作下沉,也可以將通過feign調(diào)用其他服務(wù)的接口進(jìn)行一層包裝,再提供給Service調(diào)用,這也就是所謂的防腐層。
VO、DTO、BO、DO區(qū)別
前面講解了整體的一個分層架構(gòu),那么在不同的層級之間必然需要一些模型對象進(jìn)行流轉(zhuǎn)傳遞,VO,BO,DO,DTO, 那么他們之間有什么區(qū)別呢?
- VO(View Object):視圖對象,用于展示層,它的作用是把某個指定頁面(或組件)的所有數(shù)據(jù)封裝起來。
- DTO(Data Transfer Object):數(shù)據(jù)傳輸對象,用于展示層與服務(wù)層之間的數(shù)據(jù)傳輸對象。
- BO(Business Object):業(yè)務(wù)對象,把業(yè)務(wù)邏輯封裝為一個對象,這個對象可以包括一個或多個其它的對象。
- DO(Domain Object)?:領(lǐng)域?qū)ο螅⒗锇桶鸵?guī)范中引入,此對象與數(shù)據(jù)庫表結(jié)構(gòu)一一對應(yīng),通過 DAO 層向上傳輸數(shù)據(jù)源對象。
VO和DTO什么區(qū)別??
VO?比較容易混淆的是DTO,DTO?是展示層與服務(wù)層之間傳遞數(shù)據(jù)的對象,可以這樣說,對于絕大部分的應(yīng)用場景來說,DTO和VO?的屬性值基本是一致的,而且他們通常都是POJO?,那么既然有了VO?,為什么還需要DTO呢?
例如服務(wù)層有一個getUser?的方法返回一個系統(tǒng)用戶,其中有一個屬性是gender(性別),對于服務(wù)層來說,它只從語義上定義:1-男性,2-女性,0-未指定,而對于展示層來說,它可能需要用“帥哥”代表男性,用“美女”代表女性,用“秘密”代表未指定。說到這里,可能你還會反駁,在服務(wù)層直接就返回“帥哥美女”不就行了嗎?對于大部分應(yīng)用來說,這不是問題,但設(shè)想一下,如果需求允許客戶可以定制風(fēng)格,而不同風(fēng)格對于“性別”的表現(xiàn)方式不一樣,又或者這個服務(wù)同時供多個客戶端使用(不同門戶),而不同的客戶端對于表現(xiàn)層的要求有所不同,那么,問題就來了。再者,回到設(shè)計層面上分析,從職責(zé)單一原則來看,服務(wù)層只負(fù)責(zé)業(yè)務(wù),與具體的表現(xiàn)形式無關(guān),因此,它返回的DTO,不應(yīng)該出現(xiàn)與表現(xiàn)形式的耦合。
BO和DTO的區(qū)別??
從用途上進(jìn)行根本的區(qū)別,BO是業(yè)務(wù)對象,DTO是數(shù)據(jù)傳輸對象,雖然BO也可以排列組合數(shù)據(jù),但它的功能是對內(nèi)的,但在提供對外接口時,BO對象中的某些屬性對象可能用不到或者不方便對外暴露,那么此時DTO只需要在BO的基礎(chǔ)上,抽取自己需要的數(shù)據(jù),然后對外提供。在這個關(guān)系上,通常不會有數(shù)據(jù)內(nèi)容的變化,內(nèi)容變化要么在BO內(nèi)部業(yè)務(wù)計算的時候完成,要么在解釋VO的時候完成。
我們項(xiàng)目根據(jù)實(shí)際情況總結(jié)了分層領(lǐng)域模型的規(guī)范:
- 前端傳入的參數(shù)統(tǒng)一使用DTO接收
- 由于公司是TO B項(xiàng)目,只有一個電腦web端,所以返回給展示層或者Feign返回的對象建議直接用DTO返回,特殊情況采用VO返回
- 由于歷史原因,和數(shù)據(jù)庫模型對應(yīng)的不采用DO結(jié)尾,直接用原始對象,比如學(xué)生表
student
直接使用Student
對象 - 目前很多代碼存在繼承關(guān)系,比如DTO、VO繼承數(shù)據(jù)庫對象,這個堅決不允許
項(xiàng)目目錄結(jié)構(gòu)最佳實(shí)踐
可以參考github上面的https://github.com/alvinlkk/mall4cloud這個項(xiàng)目,它是一個極度遵守阿里巴巴代碼規(guī)約的項(xiàng)目。
這里面有個關(guān)于Feign設(shè)計的亮點(diǎn), 主要是為了避免服務(wù)提供方修改了接口,而調(diào)用方?jīng)]有修改導(dǎo)致異常的問題。
- 將feign接口抽取出一個獨(dú)立的模塊
- 服務(wù)中依賴feign模塊,實(shí)現(xiàn)FeignClient
我們來看下整體的一個結(jié)構(gòu)。