參考
優秀程序員的代碼都是如何分層的？ 1、背景 2、如何進行分層 3、分層領域模型的轉換 4、總結
領域模型轉換那些事兒
1、背景
說起應用分層，大部分人都會認為這個不是很簡單嘛 就controller，service， mapper三層。看起來簡單，很多人其實並沒有把他們職責划分開，在很多代碼中，controller做的邏輯比service還多，service往往當成透傳了，這其實是很多人代碼都沒有注意到的地方，反正功能也能用，至於放哪無所謂唄。這樣往往造成后面代碼無法復用，層級關系混亂，對后續代碼的維護非常麻煩。
的確在這些人眼中分層只是一個形式，前輩們的代碼這么寫的，其他項目代碼這么寫的，那么我也這么跟着寫。但是在真正的團隊中每個人的習慣都不同，寫出來的代碼必然帶着自己的標簽，有的人習慣controller寫大量的業務邏輯，有的人習慣在service中之間調用遠程服務，這樣就導致了每個人的代碼風格完全不同，后續其他人修改的時候，一看，這個人寫的代碼和我平常的習慣完全不同，修改的時候到底是按着自己以前的習慣改，還是跟着前輩們走，這又是個艱難的選擇，選擇一旦有偏差，你的后輩又維護你的代碼的時候，恐怕就要罵人了。
所以一個好的應用分層需要具備以下幾點：方便后續代碼進行維護擴展。
分層的效果需要讓整個團隊都接受。
各個層職責邊界清晰。
2、如何進行分層
2.1、阿里規范
在阿里的編碼規范中約束的分層如下：
終端顯示層：各個端的模板渲染並執行顯示的層。當前主要是 velocity 渲染，JS 渲染， JSP 渲染，移動端展示等。
Service 層：相對具體的業務邏輯服務層。
Manager 層：通用業務處理層，它有如下特征：對第三方平台封裝的層，預處理返回結果及異常信息。
對Service層通用能力的下沉，如緩存方案、中間件通用處理。
與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中去做：
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、總結
總的來說業務分層對於代碼規范是比較重要，決定着以后的代碼是否可復用，是否職責清晰，邊界清晰。
當然這種分層其實見仁見智， 團隊中的所有人的分層習慣也不同，所以很難權衡出一個標准的准則，總的來說只要滿足職責邏輯清晰，后續維護容易，就是好的分層。
本文相關詞條概念解析：
分層
分層是表示將功能進行有序的分組：應用程序專用功能位於上層，跨越應用程序領域的功能位於中層，而配置環境專用功能位於低層。分層從邏輯上將子系統划分成許多集合，而層間關系的形成要遵循一定的規則。
代碼
代碼就是程序員用開發工具所支持的語言寫出來的源文件，是一組由字符、符號或信號碼元以離散形式表示信息的明確的規則體系。代碼設計的原則包括惟一確定性、標准化和通用性、可擴充性與穩定性、便於識別與記憶、力求短小與格式統一以及容易修改等。源代碼是代碼的分支，某種意義上來說，源代碼相當於代碼。在現代程序語言中，源代碼可以是以書籍或者磁帶的形式出現，但最為常用的格式是文本文件，這種典型格式的目的是為了編譯出計算機程序。計算機源代碼的最終目的是將人類可讀的文本翻譯成為計算機可以執行的二進制指令，這種過程叫做編譯，它由通過編譯器完成。
參考：https://www.xsrjt.com/hot/266230.html