代碼分層設計

在搭建一個項目以前，除了要進行架構和業務方面的設計和分析，每每還須要對代碼的結構進行規範化設計。而分層思想，是應用系統最多見的一種架構模式。

咱們會將系統進行橫向切割，根據業務職責劃分，這就是代碼分層。

這樣劃分的目的是規範軟件系統的邏輯結構，以便於後期開發和維護。

---

一個軟件系統就像一幅傳世名畫，在色彩和線條的表面之下，是精妙的幾何結構。

席裏柯的《梅杜莎之筏》，畫高五米，寬超七米，結構宏偉，氣勢磅礴，人體的塑造堅實而有力。尤爲是它的畫面上，由十幾我的構成了兩個金字塔式的幾何圖形。這些就是古典主義的特點。

---

上面是題外話，下面繼續介紹代碼分層。

咱們熟悉的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訪問外部數據接口的能力。

---

良好的代碼分層設計可使代碼的耦合性大大下降，易用性大大加強，爲系統的微服務化和模塊化拆分打下良好的基礎。