前言

最近review公司的代碼，發現現在整個代碼層級十分混亂，一個service類的長度甚至達到了5000多行。而且各種分層模型DTO、VO亂用， 最終出現邏輯不清晰、各模塊相互依賴、代碼擴展性差、改動一處就牽一發而動全身等問題。

我們在吸取了阿里巴巴的分層規范以及網上的一些經驗后，重新梳理總結了屬于我們項目的分層規范。

三層架構VS四層架構

我們公司原來的分層采用的是傳統的三層架構，比如在構建項目的時候，我們通常會建立三個目錄：Web、Service 和 Dao，它們分別對應了表現層、邏輯層還有數據訪問層。

這樣導致一個很大的問題，隨著業務越來越復雜，邏輯層也就是service層越來越龐大，所以出現了前面說的5000多行的類，可想而知維護成本有多大。

參照阿里發布的《阿里巴巴 Java 開發手冊 v1.4.0（詳盡版）》，我們可以將原先的三層架構細化成下面的樣子：

• 終端顯示層：各端模板渲染并執行顯示的層。當前主要是 Velocity 渲染，JS 渲染， JSP 渲染，移動端展示等。
• 開放接口層：將Service 層方法封裝成開放接口，同時進行網關安全控制和流量控制等。
• Web 層：主要是對訪問控制進行轉發，各類基本參數校驗，或者不復用的業務簡單處理等。
• Service 層：業務邏輯層。
• Manager 層：通用業務處理層。主要實現下面的功能，1） 對第三方平臺封裝的層，預處理返回結果及轉化異常信息，適配上層接口。2） 對 Service 層通用能力的下沉，如緩存方案、中間件通用處理。3） 與 DAO 層交互，對多個 DAO 的組合復用。
• DAO 層：數據訪問層，與底層 MySQL、Oracle、Hbase 等進行數據交互。
• 外部接口或第三方平臺：包括其它部門RPC 開放接口，基礎平臺，其它公司的 HTTP 接口。

在這個分層架構中主要增加了 Manager 層，它可以將Service層中的一些通用能力比如操作緩存、消息隊列的操作下沉，也可以將通過feign調用其他服務的接口進行一層包裝，再提供給Service調用，這也就是所謂的防腐層。

VO、DTO、BO、DO區別

前面講解了整體的一個分層架構，那么在不同的層級之間必然需要一些模型對象進行流轉傳遞，VO，BO，DO，DTO, 那么他們之間有什么區別呢？

• VO（View Object）：視圖對象，用于展示層，它的作用是把某個指定頁面（或組件）的所有數據封裝起來。
• DTO（Data Transfer Object）：數據傳輸對象，用于展示層與服務層之間的數據傳輸對象。
• BO（Business Object）：業務對象，把業務邏輯封裝為一個對象，這個對象可以包括一個或多個其它的對象。
• DO（Domain Object）?：領域對象，阿里巴巴規范中引入，此對象與數據庫表結構一一對應，通過 DAO 層向上傳輸數據源對象。

VO和DTO什么區別？?

VO?比較容易混淆的是DTO，DTO?是展示層與服務層之間傳遞數據的對象，可以這樣說，對于絕大部分的應用場景來說，DTO和VO?的屬性值基本是一致的，而且他們通常都是POJO?，那么既然有了VO?，為什么還需要DTO呢？

例如服務層有一個getUser?的方法返回一個系統用戶，其中有一個屬性是gender(性別)，對于服務層來說，它只從語義上定義：1-男性，2-女性，0-未指定，而對于展示層來說，它可能需要用“帥哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。說到這里，可能你還會反駁，在服務層直接就返回“帥哥美女”不就行了嗎？對于大部分應用來說，這不是問題，但設想一下，如果需求允許客戶可以定制風格，而不同風格對于“性別”的表現方式不一樣，又或者這個服務同時供多個客戶端使用（不同門戶），而不同的客戶端對于表現層的要求有所不同，那么，問題就來了。再者，回到設計層面上分析，從職責單一原則來看，服務層只負責業務，與具體的表現形式無關，因此，它返回的DTO，不應該出現與表現形式的耦合。

BO和DTO的區別??

從用途上進行根本的區別，BO是業務對象，DTO是數據傳輸對象，雖然BO也可以排列組合數據，但它的功能是對內的，但在提供對外接口時，BO對象中的某些屬性對象可能用不到或者不方便對外暴露，那么此時DTO只需要在BO的基礎上，抽取自己需要的數據，然后對外提供。在這個關系上，通常不會有數據內容的變化，內容變化要么在BO內部業務計算的時候完成，要么在解釋VO的時候完成。

我們項目根據實際情況總結了分層領域模型的規范：

1. 前端傳入的參數統一使用DTO接收
2. 由于公司是TO B項目，只有一個電腦web端，所以返回給展示層或者Feign返回的對象建議直接用DTO返回，特殊情況采用VO返回
3. 由于歷史原因，和數據庫模型對應的不采用DO結尾，直接用原始對象，比如學生表student直接使用Student對象
4. 目前很多代碼存在繼承關系，比如DTO、VO繼承數據庫對象，這個堅決不允許

項目目錄結構最佳實踐

可以參考github上面的https://github.com/alvinlkk/mall4cloud這個項目，它是一個極度遵守阿里巴巴代碼規約的項目。

這里面有個關于Feign設計的亮點, 主要是為了避免服務提供方修改了接口，而調用方沒有修改導致異常的問題。

1. 將feign接口抽取出一個獨立的模塊

2. 服務中依賴feign模塊，實現FeignClient

我們來看下整體的一個結構。

mall4cloud
├─mall4cloud-api -- 內網接口
│  ├─mall4cloud-api-auth  -- 授權對內接口
│  ├─mall4cloud-api-biz  -- biz對內接口
│  ├─mall4cloud-api-leaf  -- 美團分布式id生成接口
│  ├─mall4cloud-api-multishop  -- 店鋪對內接口
│  ├─mall4cloud-api-order  -- 訂單對內接口
│  ├─mall4cloud-api-platform  -- 平臺對內接口
│  ├─mall4cloud-api-product  -- 商品對內接口
│  ├─mall4cloud-api-rbac  -- 用戶角色權限對內接口
│  ├─mall4cloud-api-search  -- 搜索對內接口
│  └─mall4cloud-api-user  -- 用戶對內接口
├─mall4cloud-auth  -- 授權校驗模塊
├─mall4cloud-biz  -- mall4cloud 業務代碼。如圖片上傳/短信等
├─mall4cloud-common -- 一些公共的方法
│  ├─mall4cloud-common-cache  -- 緩存相關公共代碼
│  ├─mall4cloud-common-core  -- 公共模塊核心（公共中的公共代碼）
│  ├─mall4cloud-common-database  -- 數據庫連接相關公共代碼
│  ├─mall4cloud-common-order  -- 訂單相關公共代碼
│  ├─mall4cloud-common-product  -- 商品相關公共代碼
│  ├─mall4cloud-common-rocketmq  -- rocketmq相關公共代碼
│  └─mall4cloud-common-security  -- 安全相關公共代碼
├─mall4cloud-gateway  -- 網關
├─mall4cloud-leaf  -- 基于美團leaf的生成id服務
├─mall4cloud-multishop  -- 商家端
├─mall4cloud-order  -- 訂單服務
├─mall4cloud-payment  -- 支付服務
├─mall4cloud-platform  -- 平臺端
├─mall4cloud-product  -- 商品服務
├─mall4cloud-rbac  -- 用戶角色權限模塊
├─mall4cloud-search  -- 搜索模塊
└─mall4cloud-user  -- 用戶服務