說起應用分層，大部分人都會認為小Case，不就是Web應用常用的三層架構嘛，上層依賴下層，分為：Controller（Web層）、Service（業(yè)務層）、 Dao（數(shù)據(jù)層）。看起來簡單，很多人其實并沒有把他們職責劃分開，在很多代碼中，Controller做的邏輯比Service還多，Service往往當成透傳了，這其實是很多人日常開發(fā)都沒有注意到的地方，反正功能也能用，至于放哪無所謂唄。這樣往往造成后面代碼無法復用，層級關系混亂，對后續(xù)代碼的維護非常麻煩。
的確在這些人眼中分層只是一個形式，前輩們的代碼這么寫的，其他項目代碼這么寫的，那么我也這么跟著寫。但是在真正的團隊開發(fā)中每個人的習慣都不同，寫出來的代碼必然帶著自己的標簽。有的人習慣Controller寫大量的業(yè)務邏輯，有的人習慣在Service中之間調用遠程服務，這樣就導致了每個人的開發(fā)代碼風格完全不同，后續(xù)其他人修改的時候，看了一眼，非常嫌棄這個人寫的代碼和我平常的習慣完全不同?，F(xiàn)實很殘酷??！修改的時候到底是按著自己以前的習慣改，還是跟著前輩們走呢？這又是個艱難的選擇，選擇一旦有偏差，你的后輩又維護你的代碼的時候，恐怕就要罵人了。
所以一個好的應用分層需要具備以下幾點:
- 方便后續(xù)代碼進行維護擴展。
- 分層的效果需要讓整個團隊都接受。
- 各個層職責邊界清晰。
：可直接封裝 Service 方法暴露成 RPC 接口；通過 Web 封裝成 Http 接口；進行 網(wǎng)關安全控制、流量控制等。
：各個端的模板渲染并執(zhí)行顯示的層。當前主要是 Velocity 渲染，JS 渲染， JSP 渲染，移動端展示等。
主要是對訪問控制進行轉發(fā)，可以是視圖轉發(fā)或者JSON數(shù)據(jù)響應。各類基本參數(shù)校驗，或者不復用的業(yè)務簡單處理等。
：相對具體的業(yè)務邏輯服務層。
：通用業(yè)務處理層，它有如下特征:
- 對第三方平臺封裝的層，預處理返回結果及轉化異常信息。
- 對Service層通用能力的下沉，如：緩存方案、中間件通用處理。
- 與DAO層交互，對多個DAO的組合復用。
：數(shù)據(jù)訪問層，與底層 MySQL、Oracle、Hbase、Redis、ES等進行數(shù)據(jù)交互。
阿里巴巴規(guī)約中的分層比較清晰簡單明了，但是描述得還是過于簡單了，以及Service層和Manager層有很多同學還是傻傻分不清它們之間的關系，就導致了很多項目中根本沒有Manager層的存在。下下一節(jié)，將介紹一下具體業(yè)務中應該如何實現(xiàn)分層。
現(xiàn)在給出一個比較理想的模型，使用RPC框架為例，我們選用的是Thrift（下文統(tǒng)稱：TService）可能會比其他的一些RPC框架，例如：Dubbo會多出一層，作用與Web層的Controller類似。
最上層Controller和TService是阿里分層規(guī)范里面的第一層：輕業(yè)務邏輯，參數(shù)校驗，異常兜底。通常這種接口可以輕易更換接口類型，所以業(yè)務邏輯必須要輕，甚至不做具體邏輯。
：業(yè)務層，復用性較低，推薦Web層每一個Controller方法都僅對應一個Service，不要把業(yè)務邏輯放在Web層的Controller中去實現(xiàn)。業(yè)務邏輯都放到Service去實現(xiàn)，為什么呢？如果我們把業(yè)務實現(xiàn)放在Web層的Controller層去實現(xiàn)的話，如果以后我們要接入Thrift，那么這里又需要把相同的業(yè)務實現(xiàn)在做一次，這樣會導致我們每接入一個入口層的這個代碼都得重新復制一份，如下圖所示:
現(xiàn)有實現(xiàn)，業(yè)務實現(xiàn)存在于Web層Http協(xié)議訪問的CrmController，我們現(xiàn)在需要對該業(yè)務新增RPC協(xié)議支持，瓦塔西！直接在RPC實現(xiàn)調用HTTP遠程服務不合理需要復制遠程服務相同邏輯改造外，而且還需要將現(xiàn)有CrmController已實現(xiàn)的完全相同的邏輯，再在CrmThriftService實現(xiàn)一次。大量的重復工作必定會導致我們開發(fā)效率及應用可擴展性下降，所以我們需要把業(yè)務邏輯實現(xiàn)都得放進Service中去做：
：可復用邏輯層。這里的Mannager可以是單個服務實現(xiàn)，比如：我們的Cache，MQ等等。當然也可以是復合的，當你需要調用多個Mannager的時候，這個可以合為一個Mannager，比如邏輯上的連表查詢等。如果是HttpMannager或RpcMannager需要在這一層做一些數(shù)據(jù)轉換。
：數(shù)據(jù)庫訪問層。主要負責“操作數(shù)據(jù)庫的某張表，映射到Java中的DO對象”，Dao應該只允許自己的Service訪問，其他Service要訪問我的數(shù)據(jù)必須通過對應的Service進行訪問。
我們的編碼規(guī)定義了下面幾個領域模型規(guī)約：
DO（Data Object）：與數(shù)據(jù)庫表結構對應，通過Dao層向上傳輸數(shù)據(jù)源對象。
DTO（Data Transfer Object）：數(shù)據(jù)傳輸對象，Service（Dubbo服務 / RPC服務）或Manager向外傳輸?shù)膶ο蟆?/p>
BO（Business Object）：業(yè)務對象。由Service層輸出的封裝業(yè)務邏輯的對象。
AO（Application Object）：應用對象。在Web層與Service層之間抽象的復用對象模型，極為貼近展示層，復用度不高。
VO（View Object）：顯示層對象，通常是Web層向模板渲染引擎層或視圖層傳輸?shù)膶ο蟆?/p>
Query：數(shù)據(jù)查詢對象，Web層接收調用方的查詢請求。注意超過2個參數(shù)的查詢封裝，禁止使用Map類來傳輸。
Update：數(shù)據(jù)更新對象，Web層接收調用方的更新數(shù)據(jù)請求。
Form：新增數(shù)據(jù)對象，Web層接收調用方的新增數(shù)據(jù)請求。
：
| 層次 | 領域模型 |
|---|---|
| Controller / TService | VO / DTO |
| Service（Dubbo服務 / RPC服務） / Manager | AO / BO |
| Dao | DO |
每一個層基本都自己對應的領域模型，這樣就導致了我們過于追求每一層都是用自己的領域模型。這樣會導致在一次請求中，一個對象可能會出現(xiàn)3次甚至4次轉換，當返回的時候同樣也會出現(xiàn)3-4次轉換，這樣有可能一次完整的請求返回的過程，會出現(xiàn)很多次對象轉換。在開發(fā)中通過實踐證明，如果真的按照這么來操作，恐怕就別寫其他的了，一天就光寫這個重復無用的轉換邏輯算了吧！
：
- 允許Service（Dubbo服務 / RPC服務） / Manager可以操作數(shù)據(jù)領域模型（DO），對于這個層級來說，本來自己做的工作也是做的是業(yè)務邏輯處理和數(shù)據(jù)組裝。
- Controller / TService層的領域模型不允許傳入Dao層，因為這樣就不符合職責劃分了，所以必須轉換為DO傳入Dao層。
- 同理，不允許Dao層的數(shù)據(jù)傳入到Controller / TService。
：
| 層次 | 領域模型（入?yún)ⅲ?/th> | 領域模型（返回） |
|---|---|---|
| Controller / TService | Query / Update / Form | VO |
| Service（Dubbo服務 / RPC服務） / Manager | Query / Update / Form | VO |
| Dao | DO | DO |
總體來說業(yè)務分層對于代碼規(guī)范是比較重要，決定著以后的代碼是否可復用，是否可擴展，是否職責清晰，邊界清晰。
當然這種分層其實仁者見仁，智者見智，團隊中的每個成員的分層習慣也不同，所以很難權衡出一個標準的準則，總的來說只要滿足職責邏輯清晰，后續(xù)維護容易，就是好的分層。
結束前的話，如果你的團隊有更好的分層，或者上面所描述的存在什么錯誤，不合理，更好的方式，還請留言指正交流一下。
