有人說：一個人從1歲活到80歲很平凡，但如果從80歲倒着活，那麼一半以上的人都可能不凡。
生活沒有捷徑，我們踩過的坑都成為了生活的經驗，這些經驗越早知道，你要走的彎路就會越少。
1、背景
說起應用分層，大部分人都會認為這個不是很簡單嘛 就controller，service, mapper三層。看起來簡單，很多人其實并沒有把他們職責劃分開，在很多代碼中,controller做的邏輯比service還多,service往往當成透傳了，這其實是很多人開發代碼都沒有注意到的地方，反正功能也能用，至于放哪無所謂呗。這樣往往造成後面代碼無法複用，層級關系混亂，對後續代碼的維護非常麻煩。
的确在這些人眼中分層隻是一個形式，前輩們的代碼這麼寫的，其他項目代碼這麼寫的，那麼我也這麼跟着寫。但是在真正的團隊開發中每個人的習慣都不同，寫出來的代碼必然帶着自己的标簽，有的人習慣controller寫大量的業務邏輯，有的人習慣在service中之間調用遠端服務，這樣就導緻了每個人的開發代碼風格完全不同，後續其他人修改的時候，一看，我靠這個人寫的代碼和我平常的習慣完全不同，修改的時候到底是按着自己以前的習慣改，還是跟着前輩們走，這又是個艱難的選擇，選擇一旦有偏差，你的後輩又維護你的代碼的時候，恐怕就要罵人了。
是以一個好的應用分層需要具備以下幾點:
- 友善後續代碼進行維護擴充；
- 分層的效果需要讓整個團隊都接受；
- 各個層職責邊界清晰。
2、如何進行分層
2.1、阿裡規範
在阿裡的編碼規範中限制的分層如下:
開放接口層 ：可直接封裝 Service 方法暴露成 RPC 接口;通過 Web 封裝成 http 接口;進行 網關安全控制、流量控制等。
終端顯示層 ：各個端的模闆渲染并執行顯示的層。目前主要是 velocity 渲染，JS 渲染， JSP 渲染，移動端展示等。
Web 層 ：主要是對通路控制進行轉發，各類基本參數校驗，或者不複用的業務簡單處理等。
Service 層 ：相對具體的業務邏輯服務層。
Manager 層 ：通用業務處理層，它有如下特征:1. 對第三方平台封裝的層，預處理傳回結果及轉化異常資訊;2. 對Service層通用能力的下沉，如緩存方案、中間件通用處理;3. 與DAO層互動，對多個DAO的組合複用。
DAO 層 ：資料通路層，與底層 MySQL、Oracle、Hbase 進行資料互動。
阿裡巴巴規約中的分層比較清晰簡單明了，但是描述得還是過于簡單了，以及service層和manager層有很多同學還是有點分不清楚之間的關系，就導緻了很多項目中根本沒有Manager層的存在。下面介紹一下具體業務中應該如何實作分層。
2.2、優化分層
從我們的業務開發中總結了一個較為的理想模型,這裡要先說明一下由于我們的rpc架構選用的是thrift可能會比其他的一些rpc架構例如dubbo會多出一層,作用和controller層類似
圖檔最上層controller和TService是我們阿裡分層規範裡面的第一層：輕業務邏輯，參數校驗，異常兜底 。通常這種接口可以輕易更換接口類型，是以業務邏輯必須要輕，甚至不做具體邏輯。
Service ：業務層，複用性較低，這裡推薦每一個controller方法都得對應一個service,不要把業務編排放在controller中去做，為什麼呢？如果我們把業務編排放在controller層去做的話，如果以後我們要接入thrift,我們這裡又需要把業務編排在做一次，這樣會導緻我們每接入一個入口層這個代碼都得重新複制一份如下圖所示:
這樣大量的重複工作必定會導緻我們開發效率下降，是以我們需要把業務編排邏輯都得放進service中去做:
Mannager ：可複用邏輯層。這裡的Mannager可以是單個服務的，比如我們的cache,mq等等，當然也可以是複合的，當你需要調用多個Mannager的時候，這個可以合為一個Mannager，比如邏輯上的連表查詢等。如果是httpMannager或rpcMannager需要在這一層做一些資料轉換
DAO ：資料庫通路層。主要負責“操作資料庫的某張表，映射到某個java對象”，dao應該隻允許自己的Service通路，其他Service要通路我的資料必須通過對應的Service。
3、分層領域模型的轉換
在阿裡巴巴編碼規約中列舉了下面幾個領域模型規約:
- 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次轉換，這樣有可能一次完整的請求-傳回會出現很多次對象轉換。如果在開發中真的按照這麼來，恐怕就别寫其他的了，一天就光寫這個重複無用的邏輯算了吧。
是以我們得采取一個折中的方案:
1、允許Service/Manager可以操作資料領域模型，對于這個層級來說，本來自己做的工作也是做的是業務邏輯處理和資料組裝。
2、Controller/TService層的領域模型不允許傳入DAO層，這樣就不符合職責劃分了。
3、同理，不允許DAO層的資料傳入到Controller/TService。
4、總結
總的來說業務分層對于代碼規範是比較重要，決定着以後的代碼是否可複用，是否職責清晰，邊界清晰。
當然這種分層其實見仁見智, 團隊中的所有人的分層習慣也不同，是以很難權衡出一個标準的準則，總的來說隻要滿足職責邏輯清晰，後續維護容易，就是好的分層。
最後，如果你的團隊有更好的分層，或者上面所描述的有什麼錯誤的地方還請留言指正一下。
<END>
這些程式員職場“潛規則”，讓你少走5年彎路_【官方推薦】唐城的部落格-CSDN部落格