【推薦】圖中預設上層依賴於下層，箭頭關係表示可直接依賴，如：開放介面層可以依賴於web 層，也可以直接依賴於 service 層，依此類推：
dao 層：資料訪問層，與底層 mysql、oracle、hbase 等進行資料互動。
外部介面或第三方平台：包括其它部門 rpc 開放介面，基礎平台，其它公司的 http 介面。
【參考】 （分層異常處理規約）在 dao 層，產生的異常型別有很多，無法用細粒度的異常進行 catch，使用 catch(exception e)方式，並 throw new daoexception(e)，不需要列印日誌，因為日誌在 manager/service 層一定需要捕獲並列印到日誌檔案中去，如果同台伺服器再打日誌，浪費效能和儲存。在 service 層出現異常時，必須記錄出錯日誌到磁碟，盡可能帶上引數資訊，相當於保護案發現場。如果 manager 層與 service 同機部署，日誌方式與 dao層處理一致，如果是單獨部署，則採用與 service 一致的處理方式。web 層絕不應該繼續往上拋異常，因為已經處於頂層，如果意識到這個異常將導致頁面無法正常渲染，那麼就應該直接跳轉到友好錯誤頁面，加上使用者容易理解的錯誤提示資訊。開放介面層要將異常處理成錯誤碼和錯誤資訊方式返回。
編碼規約之應用分層
目錄 一 推薦 1.分層規約 二 參考 1.分層異常處理規約 2.分層領域模型規約 下圖中預設上層依賴於下層，箭頭關係表示可直接依賴。如 開放介面層可以依賴於 web 層，也可以直接依賴於 service 層，依此類推 開放介面層 可直接封裝 service 方法暴露成 rpc 介面 通過 web ...
規約先行 （二十一）設計規約
強制 儲存方案和底層資料結構的設計獲得評審一致通過，並沉澱成為文件。說明 有缺陷的底層資料結構容易導致系統風險上公升，可擴充套件性下降，重構成本也會因歷史資料遷移和系統平滑過渡而陡然增加，所以，儲存方案和資料結構需要認真地進行設計和評審，生產環境提交執行後，需要進行 double check。正例 ...
分層領域模型規約與領域模型命名規約
一 分層領域模型規約 二 領域模型命名規約 1 資料物件 do，即為資料表名。3 展示物件 vo，一般為網頁名稱。4 pojo是do dto bo vo的統稱，禁止命名成 pojo。整個web 的流程中的過程是 非常簡單的乙個圖.最近在看 人月神話 這書還不錯,旁邊乙個賣保險的哥們看到這本書的名字,...