「所有軟體問題都可以通過增加一層間接層來解決」——這句經典名言精準概括了分層架構的本質。本文將從**為什麼分層**、**分層帶來的三大核心價值**、**主流分層架構圖解與職責劃分**、**關鍵術語辨析**四個維度，為你構建完整的 Java 分層知識體系。
早期開發將所有邏輯塞進 main() 或 JSP 中，導致：
分層架構的核心動力是關注點分離：將系統按業務職責拆解為獨立層次，每層只關注單一職責，層間通過定義良好的接口交互。
以數據庫遷移為例：若 DAO 層封裝良好，從 SQL Server 遷移至 MySQL 僅需修改數據源配置與個別 SQL 方言，Service、Controller **零修改**。這是「面向接口編程」與「依賴倒置」的直接紅利。
經典比喻：繪圖邏輯 (三角形/文字) 與渲染底層 (DirectX/OpenGL) 解耦。中間插入 Renderer 接口，上層調用 drawTriangle()，下層提供 DirectXRenderer/OpenGLRenderer 實現。
孔子曰：「軟體所有問題皆可通過增加一層 Interface 解決。」團隊越大、需求變化越快、Interface 越多、依賴圖越複雜(但有序)、應對變化越從容。
成熟的 Service 層邏輯可被多個 Controller (Web、App API、定時任務、消息消費者) 復用；通用的 DAO 基類可被所有具體 DAO 繼承。重用不僅節省代碼量，更保證業務邏輯一致性。
| 層次 | 別名 | 核心職責 | 典型技術/產物 |
|---|---|---|---|
| 表現層 | UI Layer / Web Layer | 接收請求、參數校驗、視圖渲染、響應封裝 | Servlet、Spring MVC Controller、JSP/Thymeleaf、REST API |
| 業務邏輯層 | BLL / Service Layer | 核心業務規則、事務控制、異業務協調、權限校驗 | @Service、@Transactional、Domain Service |
| 數據訪問層 | DAL / DAO Layer | CRUD 操作、SQL 構建、連接池管理、緩存一致性 | MyBatis Mapper、JpaRepository、JdbcTemplate |
| 維度 | DAO (Data Access Object) | DTO (Data Transfer Object) |
|---|---|---|
| 中文名 | 數據訪問對象 | 數據傳輸對象 |
| 核心職責 | 封裝數據庫 CRUD，屏蔽持久化細節 | 層間/遠程調用數據傳輸，減少網絡開銷 |
| 典型場景 | UserDao.save(user) | 遠程 RPC 返回精簡 UserDTO(id, name, avatar) |
| 設計原則 | 接口 + 實現分離 | 可序列化、無業務邏輯、字段按需精簡 |
@Table, @Id)。formattedDate)。Servlet 本質是 **Controller (控制器)**：接收 HTTP 請求 → 解析參數 → 調用 Service → 選擇 View (JSP/JSON) → 返回響應。現代框架 (Spring MVC) 以 DispatcherServlet 為核心前端控制器，開發者編寫 @Controller 類，無需直接繼承 HttpServlet。
com.company.project.web|service|dao|entity|dto|vo|config|util。impl 包，便於 AOP 代理與多實現切換。分層架構不是教條，而是**管理複雜度的工具**。從 MVC 到三層，再到 DDD 的四層/六邊形架構，本質都是在尋找**變化點**並建立**穩定邊界**。理解每一層的「職責單一性」與「接口契約」，比死記術語定義更有價值。下次設計系統時，請問自己：「這個類若變更，會波及多少其他類？」——這就是分層好壞的試金石。
