版權歸屬：阿里巴巴集團技術團隊 著作目的：幫助更多軟體開發者搭建規範開發品臺，促進工程標準化
本文分享關於阿里巴巴Java 開發手冊使用內容的工程分層結構，為幫助大家搭建一個有規範性得應用結構。需要原PDF文檔的朋友可私信提供（小編有全套阿里《java開發手冊》各版本）。
工程結構分層
圖中默認上層依賴於下層，箭頭關係表示可直接依賴，如：開放接口層可以依賴於Web層，也可以直接依賴於Service層，依此類推：
開放接口層：可直接封裝Service接口暴露成RPC接口；通過Web封裝成http接口；網關控制層等。終端顯示層：各個端的模板渲染並執行顯示層。當前主要是velocity渲染，JS渲染，JSP渲染，移動端展示層等。Web層：主要是對訪問控制進行轉發，各類基本參數校驗，或者不復用的業務簡單處理等。Service層：相對具體的業務邏輯服務層。Manager層：通用業務處理層，它有如下特徵： 1） 對第三方平臺封裝的層，預處理返回結果及轉化異常信息； 2） 對Service層通用能力的下沉，如緩存方案、中間件通用處理； 3） 與DAO層交互，對DAO的業務通用能力的封裝。DAO層：數據訪問層，與底層MySQL、Oracle、Hbase進行數據交互。外部接口或第三方平臺：包括其它部門RPC開放接口，基礎平臺，其它公司的HTTP接口。
分層異常處理規約
在DAO層，產生的異常類型有很多，無法用細粒度異常進行catch，使用catch(Exception e)方式，並throw new DAOException(e)，不需要列印日誌，因為日誌在Manager/Service層一定需要捕獲並打到日誌文件中去，如果同臺伺服器再打日誌，浪費性能和存儲。在Service層出現異常時，必須記錄日誌信息到磁碟，儘可能帶上參數信息，相當於保護案發現場。如果Manager層與Service同機部署，日誌方式與DAO層處理一致，如果是單獨部署，則採用與Service一致的處理方式。Web層絕不應該繼續往上拋異常，因為已經處於頂層，無繼續處理異常的方式，如果意識到這個異常將導致頁面無法正常渲染，那麼就應該直接跳轉到友好錯誤頁面，儘量加上友好的錯誤提示信息。開放接口層要將異常處理成錯誤碼和錯誤信息方式返回。
分層領域模型規約：
DO（Data Object）：與資料庫表結構一一對應，通過DAO層向上傳輸數據源對象。DTO（Data Transfer Object）：數據傳輸對象，Service和Manager向外傳輸的對象。BO（Business Object）：業務對象。可以由Service層輸出的封裝業務邏輯的對象。QUERY：數據查詢對象，各層接收上層的查詢請求。註：超過2個參數的查詢封裝，禁止使用Map類來傳輸。VO（View Object）：顯示層對象，通常是Web向模板渲染引擎層傳輸的對象。
更多精彩內容，關注小伍