優秀的代碼應該如何分層

說起應用分層，大部分人都會認為這個不是很簡單嘛 就Controller，Service, Mapper三層。看起來簡單，很多人其實並沒有把他們職責劃分開，在很多代碼中,Controller做的邏輯比Service還多,Service往往當成透傳了，這其實是很多人開發代碼都沒有註意到的地方，反正功能也能用，至於放哪無所謂唄。這樣往往造成後面代碼無法復用，層級關係混亂，對後續代碼的維護非常麻煩。

一、背景

一個好的應用分層需要具備以下幾點:

1. 方便後續代碼進行維護擴展；
2. 分層的效果需要讓整個團隊都接受；
3. 各個層職責邊界清晰。

二、如何進行分層

2.1、阿裡規範

在阿裡的編碼規範中約束的分層如下:

1. 開放介面層：可直接封裝 Service 方法暴露成RPC介面;通過 Web 封裝成 http 介面;進行 網關安全控制、流量控制等。
2. 終端顯示層：各個端的模板渲染並執行顯示的層。
3. Web 層：主要是對訪問控制進行轉發，各類基本參數校驗，或者不復用的業務簡單處理等。
4. Service 層：相對具體的業務邏輯服務層。
5. Manager 層：通用業務處理層，它有如下特征:
   1. 對第三方平臺封裝的層，預處理返回結果及轉化異常信息;
   2. 對Service層通用能力的下沉，如緩存方案、中間件通用處理;
   3. 與DAO層交互，對多個DAO的組合復用。
6. DAO 層：數據訪問層，與底層 MySQL、Oracle、PostgreSQL進行數據交互。

阿裡巴巴規約中的分層比較清晰簡單明瞭，但是描述得還是過於簡單了，以及Service層和Manager層有很多同學還是有點分不清楚之間的關係，就導致了很多項目中根本沒有Manager層的存在。下麵介紹一下具體業務中應該如何實現分層。

2.2、優化分層

從我們的業務開發中總結了一個較為的理想模型：

• 最上層Controller和TService是我們阿裡分層規範裡面的第一層：輕業務邏輯，參數校驗，異常兜底。通常這種介面可以輕易更換介面類型，所以業務邏輯必須要輕，甚至不做具體邏輯。
• Service：業務層，復用性較低，這裡推薦每一個Controller方法都得對應一個Service,不要把業務編排放在Controller中去做，為什麼呢？如果我們把業務編排放在Controller層去做的話，如果以後我們要接入其他框架,我們這裡又需要把業務編排在做一次，這樣會導致我們每接入一個入口層這個代碼都得重新複製一份如下圖所示:

這樣大量的重覆工作必定會導致我們開發效率下降，所以我們需要把業務編排邏輯都得放進Service中去做:

• Mannager：可復用邏輯層。這裡的Mannager可以是單個服務的，比如我們的Cache,MQ等等，當然也可以是複合的，當你需要調用多個Mannager的時候，這個可以合為一個Mannager，比如邏輯上的連表查詢等。如果是httpMannager或rpcMannager需要在這一層做一些數據轉換。
• DAO：資料庫訪問層。主要負責“操作資料庫的某張表，映射到某個java對象”，Dao應該只允許自己的Service訪問，其他Service要訪問我的數據必須通過對應的Service。

三、分層領域模型的轉換

3.1、在阿裡巴巴編碼規約中領域模型

• DO（Data Object）：與資料庫表結構一一對應，通過DAO層向上傳輸數據源對象。
• DTO（Data Transfer Object）：數據傳輸對象，Service或Manager向外傳輸的對象。
• BO（Business Object）：業務對象。由Service層輸出的封裝業務邏輯的對象。
• AO（Application Object）：應用對象。在Web層與Service層之間抽象的復用對象模型，極為貼近展示層，復用度不高。
• VO（View Object）：顯示層對象，通常是Web向模板渲染引擎層傳輸的對象。
• Query：數據查詢對象，各層接收上層的查詢請求。註意超過2個參數的查詢封裝，禁止使用Map類來傳輸。

每一個層基本都自己對應的領域模型，這樣就導致了有些人過於追求每一層都是用自己的領域模型，這樣就導致了一個對象可能會出現3次甚至4次轉換在一次請求中，當返回的時候同樣也會出現3-4次轉換，這樣有可能一次完整的請求-返回會出現很多次對象轉換。如果在開發中真的按照這麼來，恐怕就別寫其他的了，一天就光寫這個重覆無用的邏輯算了吧。

3.2、所以我們得採取一個折中的方案:

1. 允許Service/Manager可以操作數據領域模型，對於這個層級來說，本來自己做的工作也是做的是業務邏輯處理和數據組裝
2. Controller/TService層的領域模型不允許傳入DAO層，這樣就不符合職責劃分了。
   同理，不允許DAO層的數據傳入到Controller/TService。

四、關於包名的命名:

4.1、entity、model、domain到底怎麼用？

根據很多 Java 程式員的”經驗”來看，一個資料庫表則對應著一個 Domain 對象，所以很多程式員在寫代碼時，包名則使用：com.xxx.domain ，這樣寫好像已經成為了行業的一種約束，資料庫映射對象就應該是 domain。但是你錯了，domain 是一個領域對象，往往我們再做傳統 Java 軟體 Web 開發中，這些 domain 都是貧血模型，是沒有行為的，或是沒有足夠的領域模型的行為的，所以，以這個理論來講，這些 domain 都應該是一個普通的 entity 對象，並非領域對象，所以請把包名改為:com.xxx.entity。

4.2、三句話總結下entity、model、domain的不同：

1. entity：必須和資料庫欄位一樣
2. model：前端需要什麼我們就給什麼
3. domain：很少用，代表一個對象模塊

五、總結

1. 總的來說業務分層對於代碼規範是比較重要，決定著以後的代碼是否可復用，是否職責清晰，邊界清晰。
2. 當然這種分層其實見仁見智, 團隊中的所有人的分層習慣也不同，所以很難權衡出一個標準的準則，總的來說只要滿足職責邏輯清晰，後續維護容易，就是好的分層。