分層架構深度指南關注點分離實踐祕訣 從三層式架構到洋蔥架構實施解耦與開發高品質

什麼是分層架構 (Layered Architecture)？

分層架構 (Layered Architecture) 是一種軟體設計模式，其核心在於將複雜的系統劃分為多個獨立的「層級」，並嚴格定義層與層之間的溝通邊界。最經典的實踐是 三層式架構：1. 資料層 (Data Layer) 負責數據儲存與存取；2. 業務邏輯層 (Domain/Logic Layer) 負責核心運算與流程規則；3. 展現層 (Presentation Layer) 負責使用者介面與互動。分層的主要目的是落實 關注點分離 (Separation of Concerns)，達成 高內聚與低耦合。這使得當 UI 變動或更換資料庫時，核心業務邏輯無需修改，顯著降低了系統的長期維護成本與出錯機率。

當我們買了一堆櫃子或收納盒，那最後東西到底該被收到哪邊？在居家整理中，空間的劃分決定了效率；而在軟體開發中，分層架構 (Layered Architecture) 則是決定系統能否長期維護的關鍵。

在居住空間中，樓層會有地下室、一樓、二樓等不同層並具有不同功能，地下室或一樓可以用來停車，二樓以上較常用來作為日常使用的空間。在軟體中也可以將 軟體架構設計 劃分為多層，例如資料層、業務邏輯層和展示層，每一層分別負責不同的功能，達到關注點分離 (Separation of Concerns) 的目標。

收納通常有基本原則，使用合適容器、抽屜或櫃子將相似物品放一起來隔離和保護特定物品，收納的關鍵目標是確保物品有組織地存放，以便容易找到和使用。同樣 分層架構 也有基本原則，例如將功能相關放在同一層，不同層次的隔離和保護有助於減少錯誤擴散，並確保低耦合 (Low Coupling) 和高內聚 (High Cohesion)，並將功能模組化，使其易於開發、測試和維護。

在進行軟體開發時，最重要的事情是軟體會需要持續維護、發展、接收新功能、改進和修復錯誤。程式會隨著時間過去和開發人員流動，良好的架構能讓維護成本大幅降低。

三層式架構的核心定義

程式的架構有點像蓋房子，最經典的設計就是三層式架構 (Three-Tier Architecture)，主要可以分成資料層 (Data Layer)、業務邏輯層 (Domain Layer)、展現層 (Presentation Layer)：

• 資料層 (Data Layer): 就像是底層跟房屋架構，確認後的變動最少。
• 業務邏輯層 (Domain Layer): 房子本身的格局設計，可稍微變動但變動也不多。
• 展現層 (Presentation Layer): 房子外觀裝飾或頂部加蓋，最多變動和彈性。

資料層 (Data Layer)：持久化與資料管理

資料層負責資料的儲存、檢索和管理，並提供對資料的基本操作，它包括資料庫、文件系統、外部 API 或其他資料來源。這一層關注資料的完整性、安全性和持久性，通常使用資料庫管理系統 (如 MySQL、MongoDB 等) 來提供基本的 CRUD 操作。資料層通常透過業務邏輯層來操作，以進行檢索和儲存資料。

業務邏輯層 (Domain Layer)：系統的核心規則

業務邏輯層是程式的核心，負責管理程式的核心業務邏輯、流程控制。它位於資料層和展現層之間，確保資料在不同層級之間的正確處理。這也是軟體架構設計中最穩定、最需要保護的部分，應盡量避免直接依賴外部框架。業務邏輯層通常訪問資料層以檢索和更新資料，同時提供程式界面 (API) 供展現層使用。

展現層 (Presentation Layer)：使用者互動介面

展現層負責將資料呈現給最終用戶，包括用戶界面 (UI)、網頁、App 等。這一層關注用戶體驗與互動設計。它負責接收用戶輸入並傳遞給業務邏輯層，同時將結果回傳顯示。

分層架構在前端 React 中的實務應用

在現代前端開發中，雖然我們常在一個元件裡寫完所有邏輯，但為了提升可維護性，我們同樣會實踐分層：

1. Presentation (展示元件)：純粹負責渲染 UI 的元件。
2. Logic (Custom Hooks)：將業務邏輯或狀態管理抽離至 Hook 中。
3. Data Access (API Service)：將 API 呼叫單獨封裝，不讓元件直接處理 fetch 邏輯。

透過這種分層，當 API 格式改變時，你只需要修改 Service 層，而不必動到 UI 元件。

可維護的程式碼

任何熟悉該領域的開發人員都應該能夠：

• 對功能進行優化和問題修復，並不破壞底層的東西。
• 快速理解程式碼並知道在哪裡進行更改。

目標是當程式在做修改的時候，業務邏輯應該要能夠穩定的被持續測試：

• 修改展現層不應破壞任何業務邏輯。
• 修改資料庫不應影響軟體的業務規則。

回到怎麼選擇套件的問題，在程式撰寫上我們要要注意新撰寫的程式對架構的影響：

• 穿透性: 原則上不是穿透原本程式架構的設計，像 Redux 就屬於可以穿透在每個角落的一個套件，以 Redux 來說就像是硬裝潢，裝下去之後做更動的成本就非常高。
• 影響範圍: 是否容易被替代，跟原本的做法會不會差很多，是否需要重寫，像一般的表格換成 Aggrid 就相當於重寫。

以剛剛的三層式架構來說，也有人把三層變體成一圈一圈的洋蔥式架構（Onion Architecture），並針對功能分層製作，每一層都有自己的焦點。掌握分層架構的關鍵在於：內圈（核心邏輯）不應知道外圈（實作細節）的存在。

內圈中任何事物都無法了解外圈中的任何事物。其中包括函數、類別、變數或任何其他命名的軟體實體。
—— Robert Cecil Martin

那該怎麼寫出好的架構呢? 下一篇文章小編會繼續帶大家看下去。

FAQ：分層架構常見問題

Q1：小型專案或簡單的腳本也需要分層嗎？

A：不建議過度設計。 如果您的專案只是幾十行的處理腳本，強行拆分為 Data/Domain/Presentation 層只會增加開發負擔。分層架構的投資回報點在於「長期維護」與「團隊協作」。對於快速原型 (POC)，KISS 原則通常比 Layered Architecture 更優先。

Q2：為什麼業務邏輯層 (Domain Layer) 被視為最穩定的一層？

A：因為業務邏輯反映的是「商業本質」。例如：一個電商系統的「結帳流程規則」通常不隨您是用 React 還是 Vue 顯示、也不隨您是用 MySQL 還是 PostgreSQL 儲存而改變。保持業務層的純粹，能確保系統在技術棧更叠時依然穩健。

Q3：分層過多會導致效能問題（如頻繁的物件轉換）嗎？

A：在極端高效能要求的場景中，分層間的資料傳遞（例如將 DB Entity 轉為 Domain Model，再轉為 DTO）確實會帶來細微的 overhead。但對於 95% 的 Web 應用來說，這些開銷相對於「開發效率與維護成本」的降低是微不足道的。應優先追求程式碼的可讀性。

• ← 上一篇
• 下一篇 →