在搭建一個專案之前，除了要進行架構和業務方面的設計和分析，往往還需要對程式碼的結構進行規範化設計。而分層思想，是應用系統最常見的一種架構模式。
我們會將系統進行橫向切割，根據業務職責劃分，這就是程式碼分層。
這樣劃分的目的是規範軟體系統的邏輯結構，以便於後期開發和維護。
一個軟體系統就像一幅傳世名畫，在色彩和線條的表面之下，是精妙的幾何結構。
席裡柯的《梅杜莎之筏》，畫高五米，寬超七米，結構巨集偉，氣勢磅礴，人體的塑造堅實而有力。尤其是它的畫面上，由十幾個人構成了兩個金字塔式的幾何圖形。這些就是古典主義的特色。
上面是題外話，下面繼續介紹程式碼分層。
我們熟悉的MVC(Model-View-Controller，分別是模型層、檢視層、控制層)三層架構就是非常典型的分層架構模式。
它將頁面和業務邏輯分離，提高應用的可擴充套件性及可維護性。
MVC 三層架構只是概念層面的指導思想，如果想要讓開發更規範、職責更明確、層次更清晰，需要下面更為細緻的程式碼分層設計。
在介紹程式碼的分層之前，需要先了解程式碼分層結構中的領域模型。
領域模型
下面介紹幾個常用的領域模型，其中參考了阿里巴巴編碼規範的設計。
DO
DO（Data Object）與資料庫表結構一一對應，通過 DAO 層向上傳輸資料來源物件。
DTO
DTO（Data Transfer Object）是遠端呼叫物件，它是 RPC 服務提供的領域模型。
需要注意的是，對於 DTO 一定要保證其序列化，實現 Serializable 介面，並顯示提供 serialVersionUID，否則在反序列化時，如果 serialVersionUID 被修改，那麼反序列化會失敗。
BO
BO（Business Object）是業務邏輯層封裝業務邏輯的物件，一般情況下，它是聚合了多個資料來源的複合物件。
VO
VO（View Object） 通常是請求處理層傳輸的物件，它通過 Spring 框架的轉換後，往往是一個 JSON 物件。
程式碼分層
在傳統的MVC三層結構的基礎之上，我們將業務系統設計為如下四層結構：前端層、請求處理層、業務邏輯層和持久層。
下面詳細介紹一下各個分層的作用。
前端層
前端層的內容涵蓋了從系統外發起的一切請求，還包括定時任務的觸發配置，以及系統的監控和檢測程式。
請求處理層
請求處理層的作用包括通過模板引擎(FreeMarket、Velocity等)的頁面渲染、封裝RESTful API的HTTP介面，以及暴露給前端呼叫的各種型別的介面。
業務邏輯層
業務邏輯層的職責是與資料持久層互動，包括對多個資料來源的操作進行聚合，並且提供組合複用的能力。
如果網站採用分散式架構，或者資料庫需要分庫，也包括對RPC服務的統一呼叫，為了減少不必要的重複呼叫RPC服務，RPC Service中對資料進行統一處理以後再返回給Manager，是一個節省RPC連線的做法。
此外，它也是業務通用能力的處理層，其中還包括快取方案、訊息監聽（MQ）、定時任務、引數校驗、資料轉換、異常處理等。
資料持久層
資料持久層承載了資料儲存和訪問的能力。包括通過DAO訪問資料庫的能力和通過DAP訪問外部資料介面的能力。
良好的程式碼分層設計可以使程式碼的耦合性大大降低，易用性大大增強，為系統的微服務化和模組化拆分打下良好的基礎。