前言
在做一個小型的管理系統的時候，有同學說他的功能都能實現，但是就是代碼比較凌亂，時間久了就不知道各個包放的啥，有什麼功能。
我覺得不僅要有良好的寫代碼習慣，也要有好的分層意識。不能因為是初學者就忽視這個問題，因為好的習慣能給你帶很多方便，也為未來做項目打下基礎。習慣不好以後改過來挺麻煩的。
因此最近看了一些大牛的文章，做了一些整理：
首先說一下我們初學者學的MVC設計模式
通過這個模式就會更好的理解最新的結構分層思想
MVC模式
阿里的編碼規範中約束的分層
一個好的分層，應該具備以下特點：
- 方便後續代碼進行維護擴展
- 分層效果需要讓整個團隊接受，要始終明白未來的項目不是你一個人完成的。在一開始我覺得我們就應該有這樣的思想準備。
- 各層職責邊界清晰
開放接口層：可直接封裝 Service 方法暴露成 RPC 接口;通過 Web 封裝成 http 接口;進行 網關安全控制、流量控制等。
終端顯示層：各個端的模板渲染並執行顯示的層。當前主要是 velocity 渲染，JS 渲染， JSP 渲染，移動端展示等。
Web 層：主要是對訪問控制進行轉發，各類基本參數校驗，或者不復用的業務簡單處理等。
Service 層：相對具體的業務邏輯服務層。
Manager 層：通用業務處理層，它有如下特徵:1. 對第三方平臺封裝的層，預處理返回結果及轉化異常信息;2. 對Service層通用能力的下沉，如緩存方案、中間件通用處理;3. 與DAO層交互，對多個DAO的組合複用。
DAO 層：數據訪問層，與底層 MySQL、Oracle、Hbase 進行數據交互。
阿里巴巴規約中的分層比較清晰簡單明瞭，但是描述得還是過於簡單了，以及service層和manager層有很多同學還是有點分不清楚之間的關係，就導致了很多項目中根本沒有Manager層的存在。
優化分層
Mannager：可複用邏輯層。這裡的Mannager可以是單個服務的，比如我們的cache,mq等等，當然也可以是複合的，當你需要調用多個Mannager的時候，這個可以合為一個Mannager，比如邏輯上的連表查詢等。如果是httpMannager或rpcMannager需要在這一層做一些數據轉換
DAO：數據庫訪問層。主要負責“操作數據庫的某張表，映射到某個java對象”，dao應該只允許自己的Service訪問，其他Service要訪問我的數據必須通過對應的Service
註明
由於涉及到新的框架內容（rpc），還沒有學習到，因此這部分暫時不做整理，我會再抽個時間整理。
感興趣的可以查看這篇文章：
https://m.toutiaocdn.com/item/6727538635094114824/?app=news_article×tamp=1566481699&req_id=201908222148190101520391973492596&group_id=6727538635094114824
