軟體架構原則之“分層架構”小結
如果你不知道要用什麼架構，那就用它，可以用在業務上也可以用在技術上。這種架構將軟體分成若干個水平層，每一層都有清晰的角色和分工，不需要知道其他層的細節，層與層之間隔離通過介面通訊，序列依賴。
分層架構
核心點：
- 單向依賴，一層只依賴一層，不跨層
- 抽象隔離，分的越開越好，哪怕是異地
好處：
- 程式碼結構清晰易於理解
- 程式碼複雜度降低，容易理解和開發
- 層間隔離，利於排查問題
- 後期的維護升級方便而簡單
- 每一層都可以獨立測試，其他層的介面通過模擬解決
- 不同技能的程式設計師可以分工，負責不同的層
- 天然適合大多數軟體公司的組織架構
- 抽象邏輯複用起來簡單
分層思想的真理：
電腦科學領域任何問題，都可以間接的通過新增一箇中間層來解決。
分層採用的方法：
- 單個專案的可採用package方式
com.xxx.core
-- .service
-- .mapper
-- .util
-- .controller
-- .dao
-- .model
- 多層專案的採用引入獨立jar方式
paper-parent
-- paper-common
-- paper-core
-- paper-core-api
-- paper-core-service
-- paper-rest
- 微服務式分層
企業架構 -- 基礎服務層：使用者、訂單、認證等 -- 應用層：各產品分離 -- 等等
分層介紹
Web型專案的B/S架構中經典分層策略“MVC架構”。這種架構一般的現在工具類的專案中，View採用java渲染引擎JSP（Velocity\Freemaker\Thyemleaf\等），但是主流的網際網路平臺都是前後端分離型專案，前端是獨立構建和釋出模式（npm大前端趨勢），後端以介面方式提供服務。
乾貨分享：目前正在使用的分層架構圖，歡迎討論
表現層
有時候也說是客戶端層，不論是App還是Web或者其他，指客戶直接接觸到的頁面。Web前端架構後期會單獨來詳細介紹，這裡就一筆帶過了。
介面層
- 採用Service提供RPC介面服務
- 通過Web封裝成Http介面服務
靠譜說絕大多數公司就兩種服務形式：RPC 和 HTTP。統一規範的返回結果和異常的全域性處理是必不可少的。這層不可以丟擲異常，否則會導致client會出現不可控的錯誤，通過標準的ErrorCode&ErrorMeg提示，一般還會有流量控制和許可權等控制監控在這層。
服務層（業務）
所有的業務實現放在這層，一般可以按照業務型別分類也便於識別管理；事務也放在這層，一般推薦只放在這層統一管理。
業務層所負責的：
- 處理應用程式的業務邏輯和業務校驗。
- 管理事務。
- 提供與其他層相互作用的介面。
- 管理業務層級別的物件的依賴。
- 在表示層和持久層之間增加一個靈活的機制，使得他們不直接聯絡在一起。
- 通過揭示從表示層到業務層之間的上下文來得到業務邏輯。
- 管理程式的執行（從業務層到持久層）。
持久層
主要有資料庫的entity對映類，只提供簡單CRUD的dao操作類，介面mapper類，一些連線中介軟體的封裝util工具類；這層推薦嚴格禁止事務，異常可以統一封裝一個OrmException對服務層提供。
資料層（儲存）
資料層指儲存，根據業務選擇的資料儲存基礎設施，傳統的關係型資料庫Mysql、Oracle，Nosql資料庫Redis、ES、Mongodb等。不同的資料庫採用的connect方式不同，需要在持久層獨立封裝一個獨立Util類進行集中管理。
dubbo專案的分層結構：
推薦
作者: Owen Jia，他的部落格：Owen Blog
轉載請著