1. 阿里java框架分層構(gòu)建細(xì)細(xì)研究，確實(shí)按照這樣方式開發(fā)的話，業(yè)務(wù)更加清晰，代碼更加整潔值得我們學(xué)學(xué)習(xí)與思考。  

2.     【推薦】圖中默認(rèn)上層依賴于下層，箭頭關(guān)系表示可直接依賴，如：開放接口層可以依賴于Web層，也可以直接依賴于Service層，依此類推：  

1.應(yīng)用分層    

    開放接口層    可直接封裝Service接口暴露成RPC接口；通過Web封裝成http接口；網(wǎng)關(guān)控制層等。   

    終端顯示層：各個端的模板渲染并執(zhí)行顯示層。當(dāng)前主要是velocity渲染，JS渲染，JSP渲染，移動端展示層等。 

    Web層：主要是對訪問控制進(jìn)行轉(zhuǎn)發(fā)，各類基本參數(shù)校驗(yàn)，或者不復(fù)用的業(yè)務(wù)簡單處理等。 

    Service層：相對具體的業(yè)務(wù)邏輯服務(wù)層。 

    Manager層：通用業(yè)務(wù)處理層，它有如下特征：  

        1） 對第三方平臺封裝的層，預(yù)處理返回結(jié)果及轉(zhuǎn)化異常信息；  

        2） 對Service層通用能力的下沉，如緩存方案、中間件通用處理；   

        3） 與DAO層交互，對DAO的業(yè)務(wù)通用能力的封裝。 

    DAO層：數(shù)據(jù)訪問層，與底層Mysql、Oracle、Hbase、OB進(jìn)行數(shù)據(jù)交互。  外部接口或第三方平臺：包括其它部門RPC開放接口，基礎(chǔ)平臺，其它公司的HTTP接口。   

2. 【參考】（分層異常處理規(guī)約）在DAO層，  

    產(chǎn)生的異常類型有很多，無法用細(xì)粒度異常進(jìn)行catch，使用catch(Exception e)方式，  

    并throw new DaoException(e)，不需要打印日志，因?yàn)槿罩驹贛anager/Service層一定需要捕獲并打到日志文件中去，如果同臺服務(wù)器再打日志  

    ，浪費(fèi)性能和存儲。在Service層出現(xiàn)異常時，必須記錄日志信息到磁盤，盡可能帶上參數(shù)信息，相當(dāng)于保護(hù)案發(fā)現(xiàn)場。如果Manager層與Service同機(jī)部署，  

    日志方式與DAO層處理一致，如果是單獨(dú)部署，則采用與Service一致的處理方式。Web層絕不應(yīng)該繼續(xù)往上拋異常，因?yàn)橐呀?jīng)處于頂層，無繼續(xù)處理異常的方式，  

    如果意識到這個異常將導(dǎo)致頁面無法正常渲染，那么就應(yīng)該直接跳轉(zhuǎn)到友好錯誤頁面，盡量加上友好的錯誤提示信息。開放接口層要將異常處理成錯誤碼和錯誤信息方式返回。   

3. 【參考】分層領(lǐng)域模型規(guī)約： 

    DO（Data Object）：與數(shù)據(jù)庫表結(jié)構(gòu)一一對應(yīng)，通過DAO層向上傳輸數(shù)據(jù)源對象。 

    DTO（Data Transfer Object）：數(shù)據(jù)傳輸對象，Service和Manager向外傳輸?shù)膶ο蟆?nbsp;

    BO（Business Object）：業(yè)務(wù)對象?？梢杂蒘ervice層輸出的封裝業(yè)務(wù)邏輯的對象。 

    QUERY：數(shù)據(jù)查詢對象，各層接收上層的查詢請求。注：超過2個參數(shù)的查詢封裝，禁止使用Map類來傳輸。 

    VO（View Object）：顯示層對象，通常是Web向模板渲染引擎層傳輸?shù)膶ο蟆? 

出處：https://blog.csdn.net/u011687186/article/details/55511043