工程規約
1.應用分層
圖中默認上層依賴於下層，箭頭關係表示可直接依賴，如：開放接口層可以依賴於Web層，也可以直接依賴於 Service層
開放接口層：可直接封裝 Service接口暴露成 RPC接口；通過 Web封裝成 http接口；網關控制層等。
終端顯示層：各個端的模板渲染並執行顯示層。當前主要是 velocity渲染，JS渲染，JSP渲染，移動端展示層等。
Web層：主要是對訪問控制進行轉發，各類基本參數校驗，或者不復用的業務簡單處理等。
Service層：相對具體的業務邏輯服務層。
Manager層：通用業務處理層，它有如下特徵：
1） 對第三方平臺封裝的層，預處理返回結果及轉化異常信息；
2） 對 Service層通用能力的下沉，如緩存方案、中間件通用處理；
3） 與 DAO層交互，對 DAO的業務通用能力的封裝。
DAO層：數據訪問層，與底層 Mysql、Oracle、Hbase、OB進行數據交互。
外部接口或第三方平臺：包括其它部門 RPC開放接口，基礎平臺，其它公司的 HTTP接口。
2（分層異常處理規約）
在 DAO層，產生的異常類型有很多，無法用細粒度異常進行catch，使用 catch(Exception e)方式，並 throw new DaoException(e)，不需要打印日誌，
因爲日誌在 Manager/Service層一定需要捕獲並打到日誌文件中去，如果同臺服務器再打日誌，浪費性能和存儲。在 Service層出現異常時，必須記錄日誌信息到磁盤，儘可能
帶上參數信息，相當於保護案發現場。如果 Manager層與 Service同機部署，日誌方式與 DAO層處理一致，如果是單獨部署，則採用與 Service一致的處理方式。
Web層絕不應該繼續往上拋異常，因爲已經處於頂層，無繼續處理異常的方式，如果意識到這個異常將導致頁面無法正常渲染，那麼就應該直接跳轉到友好錯誤頁面，
儘量加上友好的錯誤提示信息。開放接口層要將異常處理成錯誤碼和錯誤信息方式返回。
3.分層領域模型規約：
· DO（Data Object）：與數據庫表結構一一對應，通過 DAO層向上傳輸數據源對象。
· DTO（Data Transfer Object）：數據傳輸對象，Service和 Manager向外傳輸的對象。
· BO（Business Object）：業務對象。可以由 Service層輸出的封裝業務邏輯的對象。
· QUERY：數據查詢對象，各層接收上層的查詢請求。注：超過 2個參數的查詢封裝，禁止使用 Map類來傳輸。
· VO（View Object）：顯示層對象，通常是 Web向模板渲染引擎層傳輸的對象。
二方庫規約
定義 GAV遵從以下規則：
1） GroupID格式：com.{公司/BU }.業務線.[子業務線]，最多 4級。
說明：{公司/BU} 例如：alibaba/taobao/tmall/aliexpress等 BU一級；子業務線可選。
正例：com.taobao.jstorm 或 com.alibaba.dubbo.register
2） ArtifactID格式：產品線名-模塊名。語義不重複不遺漏，先到倉庫中心去查證一下。
正例：dubbo-client / fastjson-api / jstorm-tool
3） Version：詳細規定參考下方
二方庫版本號命名方式：主版本號.次版本號.修訂號
1） 主版本號：當做了不兼容的 API修改，或者增加了能改變產品方向的新功能。
2） 次版本號：當做了向下兼容的功能性新增（新增類、接口等）。
3） 修訂號：修復 bug，沒有修改方法簽名的功能加強，保持 API 兼容性。
注意起始版本號必須爲：1.0.0，而不是0.0.1，正式發佈的類庫必須先去中央倉庫進行查證，使版本號有延續性，正式版本號不允許覆蓋升級
4.線上應用不要依賴 SNAPSHOT版本（安全包除外）；正式發佈的類庫必須使用 RELEASE版本號升級+1的方式，且版本號不允許覆蓋升級，必須去中央倉庫進行查證。
說明：不依賴 SNAPSHOT版本是保證應用發佈的冪等性。另外，也可以加快編譯時的打包構建。
5.二方庫的新增或升級，保持除功能點之外的其它 jar包仲裁結果不變。如果有改變，必須明確評估和驗證，建議進行 dependency:resolve前後信息比對，
如果仲裁結果完全不一致，那麼通過 dependency:tree命令，找出差異點，進行<excludes>排除 jar包。