1.背景
說起應用分層端朵，大部分人都會認為這個不是很簡單嘛 就controller好芭，service, mapper三層〕迥兀看起來簡單舍败，很多人其實并沒有把他們職責劃分開，在很多代碼中,controller做的邏輯比service還多,service往往當成透傳了敬拓，這其實是很多人開發(fā)代碼都沒有注意到的地方邻薯，反正功能也能用，至于放哪無所謂唄乘凸。這樣往往造成后面代碼無法復用厕诡，層級關系混亂，對后續(xù)代碼的維護非常麻煩营勤。2021Java面試寶典
的確在這些人眼中分層只是一個形式灵嫌，前輩們的代碼這么寫的，其他項目代碼這么寫的葛作，那么我也這么跟著寫寿羞。但是在真正的團隊開發(fā)中每個人的習慣都不同，寫出來的代碼必然帶著自己的標簽进鸠，有的人習慣controller寫大量的業(yè)務邏輯稠曼，有的人習慣在service中之間調用遠程服務，這樣就導致了每個人的開發(fā)代碼風格完全不同，后續(xù)其他人修改的時候霞幅，一看漠吻，我靠這個人寫的代碼和我平常的習慣完全不同，修改的時候到底是按著自己以前的習慣改司恳，還是跟著前輩們走途乃，這又是個艱難的選擇，選擇一旦有偏差扔傅，你的后輩又維護你的代碼的時候耍共，恐怕就要罵人了。
所以一個好的應用分層需要具備以下幾點:
方便后續(xù)代碼進行維護擴展猎塞。
分層的效果需要讓整個團隊都接受
各個層職責邊界清晰
2.如何進行分層
2.1阿里規(guī)范
在阿里的編碼規(guī)范中約束的分層如下:
開放接口層: 可直接封裝 Service 方法暴露成 RPC 接口;通過 Web 封裝成 http 接口;進行 網關安全控制试读、流量控制等。
終端顯示層: 各個端的模板渲染并執(zhí)行顯示的層荠耽。當前主要是 velocity 渲染钩骇，JS 渲染， JSP 渲染铝量，移動端展示等倘屹。
Web 層: 主要是對訪問控制進行轉發(fā)，各類基本參數校驗慢叨，或者不復用的業(yè)務簡單處理等纽匙。
Service 層: 相對具體的業(yè)務邏輯服務層。
Manager 層: 通用業(yè)務處理層拍谐，它有如下特征:1. 對第三方平臺封裝的層烛缔，預處理返回結果及轉化異常信息;2. 對Service層通用能力的下沉，如緩存方案赠尾、中間件通用處理;3. 與DAO層交互力穗，對多個DAO的組合復用毅弧。
DAO 層: 數據訪問層气嫁，與底層 MySQL、Oracle够坐、Hbase 進行數據交互寸宵。
阿里巴巴規(guī)約中的分層比較清晰簡單明了，但是描述得還是過于簡單了元咙，以及service層和manager層有很多同學還是有點分不清楚之間的關系梯影，就導致了很多項目中根本沒有Manager層的存在。下面介紹一下具體業(yè)務中應該如何實現分層
2.2優(yōu)化分層
從我們的業(yè)務開發(fā)中總結了一個較為的理想模型,這里要先說明一下由于我們的rpc框架選用的是thrift可能會比其他的一些rpc框架例如dubbo會多出一層,作用和controller層類似
1.最上層controller和TService是我們阿里分層規(guī)范里面的第一層: 輕業(yè)務邏輯庶香，參數校驗甲棍，異常兜底。通常這種接口可以輕易更換接口類型,所以業(yè)務邏輯必須要輕赶掖，甚至不做具體邏輯感猛。
2.Service： 業(yè)務層七扰，復用性較低，這里推薦每一個controller方法都得對應一個service,不要把業(yè)務編排放在controller中去做陪白，為什么呢颈走？
如果我們把業(yè)務編排放在controller層去做的話，如果以后我們要接入thrift,我們這里又需要把業(yè)務編排在做一次咱士，這樣會導致我們每接入一個入口層這個代碼都得重新復制一份如下圖所示:
這樣大量的重復工作必定會導致我們開發(fā)效率下降立由，所以我們需要把業(yè)務編排邏輯都得放進service中去做:
3.Mannager： 可復用邏輯層。這里的Mannager可以是單個服務的序厉，比如我們的cache,mq等等锐膜，當然也可以是復合的，當你需要調用多個Mannager的時候弛房，這個可以合為一個Mannager枣耀，比如邏輯上的連表查詢等。如果是httpMannager或rpcMannager需要在這一層做一些數據轉換
4.DAO： 數據庫訪問層庭再。主要負責“操作數據庫的某張表捞奕，映射到某個java對象”，dao應該只允許自己的Service訪問拄轻，其他Service要訪問我的數據必須通過對應的Service颅围。
3.分層領域模型的轉換
在阿里巴巴編碼規(guī)約中列舉了下面幾個領域模型規(guī)約:
DO（Data Object）：與數據庫表結構一一對應，通過DAO層向上傳輸數據源對象恨搓。
DTO（Data Transfer Object）：數據傳輸對象院促，Service或Manager向外傳輸的對象。
BO（Business Object）：業(yè)務對象斧抱。由Service層輸出的封裝業(yè)務邏輯的對象常拓。
AO（Application Object）：應用對象。在Web層與Service層之間抽象的復用對象模型辉浦，極為貼近展示層弄抬，復用度不高。
VO（View Object）：顯示層對象宪郊，通常是Web向模板渲染引擎層傳輸的對象掂恕。
Query：數據查詢對象，各層接收上層的查詢請求弛槐。注意超過2個參數的查詢封裝懊亡，禁止使用Map類來傳輸。
每一個層基本都自己對應的領域模型乎串，這樣就導致了有些人過于追求每一層都是用自己的領域模型店枣，這樣就導致了一個對象可能會出現3次甚至4次轉換在一次請求中，當返回的時候同樣也會出現3-4次轉換，這樣有可能一次完整的請求-返回會出現很多次對象轉換鸯两。如果在開發(fā)中真的按照這么來坏瞄，恐怕就別寫其他的了，一天就光寫這個重復無用的邏輯算了吧甩卓。
所以我們得采取一個折中的方案:
允許Service/Manager可以操作數據領域模型鸠匀，對于這個層級來說，本來自己做的工作也是做的是業(yè)務邏輯處理和數據組裝逾柿。
Controller/TService層的領域模型不允許傳入DAO層缀棍，這樣就不符合職責劃分了。
同理机错，不允許DAO層的數據傳入到Controller/TService.
4.總結
總的來說業(yè)務分層對于代碼規(guī)范是比較重要爬范，決定著以后的代碼是否可復用，是否職責清晰弱匪，邊界清晰青瀑。
當然這種分層其實見仁見智, 團隊中的所有人的分層習慣也不同，所以很難權衡出一個標準的準則萧诫，總的來說只要滿足職責邏輯清晰斥难，后續(xù)維護容易，就是好的分層帘饶。2021Java面試寶典
最后哑诊，如果你的團隊有更好的分層，或者上面所描述的有什么錯誤的地方還請留言指正一下及刻。
