1. 【推薦】圖中默認上層依賴于下層，箭頭關系表示可直接依賴，如：開放接口層可以依賴于 Web層，也可以直接依賴于Service層，依此類推：  ? 開放接口層：可直接封裝Service方法暴露成RPC接口；通過Web封裝成http接口；進行網關安全控制、流量控制等。 ? 終端顯示層：各個端的模板渲染并執行顯示的層。當前主要是velocity渲染，JS渲染， JSP渲染，移動端展示等。 ? Web層：主要是對訪問控制進行轉發，各類基本參數校驗，或者不復用的業務簡單處理等。 ? Service層：相對具體的業務邏輯服務層。 ? Manager層：通用業務處理層，它有如下特征： 1） 對第三方平臺封裝的層，預處理返回結果及轉化異常信息； 2） 對Service層通用能力的下沉，如緩存方案、中間件通用處理； 3） 與DAO層交互，對多個DAO的組合復用。 ? DAO層：數據訪問層，與底層MySQL、Oracle、Hbase等進行數據交互。 ? 外部接口或第三方平臺：包括其它部門RPC開放接口，基礎平臺，其它公司的HTTP接口。 1. 【參考】 （分層異常處理規約）在DAO層，產生的異常類型有很多，無法用細粒度的異常進 行catch，使用catch(Exception e)方式，并throw new DAOException(e)，不需要打印日志，因為日志在Manager/Service層一定需要捕獲并打到日志文件中去，如果同臺服務器再打日志，浪費性能和存儲。在Service層出現異常時，必須記錄出錯日志到磁盤，盡可能帶上參數信息，相當于保護案發現場。如果Manager層與Service同機部署，日志方式與DAO 層處理一致，如果是單獨部署，則采用與Service一致的處理方式。Web層絕不應該繼續往上拋異常，因為已經處于頂層，如果意識到這個異常將導致頁面無法正常渲染，那么就應該直接跳轉到友好錯誤頁面，加上用戶容易理解的錯誤提示信息。開放接口層要將異常處理成錯誤碼和錯誤信息方式返回。 1. 【參考】分層領域模型規約： ? 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類來傳輸。