Layered Architecture 是大多數人學會的第一個架構模式，也是很多系統在沒有刻意選擇任何架構的情況下自然長成的樣子。
把系統分成三層：
- Presentation Layer（HTTP handler、Controller、View）：處理 HTTP 請求，解析輸入，回傳結果
- Business Layer（Service、Domain Logic）：業務規則，不知道 HTTP，不知道 DB
- Data Access Layer（Repository、ORM、DAO）：和資料庫打交道，不知道業務邏輯
這個分法有明確的直覺：UI 在最上面，資料庫在最下面，業務邏輯在中間。呼叫方向是從上到下，Presentation 呼叫 Business，Business 呼叫 Data。
三層架構在哪裡對
三層架構解決了最基本的問題：把業務邏輯從 HTTP handler 裡分離出來。
沒有分層的系統是什麼樣？Controller 裡有 100 行業務邏輯，直接呼叫 SQL，所有東西混在一起。改一個業務規則可能要動 HTTP 解析邏輯，改一個 API response 格式可能要動資料庫查詢。這是分層要解決的根本問題。
三層架構解決了這個問題，對大多數中小型系統這就夠了。它的學習成本幾乎是零，大多數框架（Spring MVC、Django、Laravel、Rails）預設就是這個結構，每個加入團隊的開發者立刻知道 code 放哪裡。
它撞牆的地方
三層架構最大的問題是沒有規範依賴方向。理論上是上層呼叫下層，但沒有機制阻止 Business Layer 直接 import Presentation 層的物件，或 Data Layer 引用 Business 的類別。
時間久了，你會看到：
- Controller 直接呼叫 Repository（跳過 Service）
- Service 直接操作 HTTP Request 物件（知道 Presentation 的細節）
- DAO 裡有一段業務規則（因為 SQL 查詢最方便放在那裡）
三層的邊界是靠命名慣例和 code review 維持的，不是靠架構本身強制的。大型系統或多人協作的長期專案，這個邊界很難守住。
另一個問題是 Business Layer 通常直接依賴 Data Layer 的具體實作——UserService 直接用 PostgresUserRepository，換資料庫要動 Business Layer。這和「業務邏輯不應該知道資料庫細節」的原則衝突。
這兩個問題，是 Clean Architecture 和 Hexagonal Architecture 後來被提出的原因——它們都在三層架構的基礎上加了「依賴倒置」：Business Layer 定義介面，Data Layer 實作介面，依賴方向反過來了。
三層架構的合理使用場景
三層不是過時的架構——它是正確場景的正確選擇。
CRUD 系統、小型 API 服務、MVP 產品、工具性後端——業務邏輯簡單、團隊小、不需要換資料庫的系統，三層架構的低複雜度是優勢，不是缺點。引入 Clean Architecture 的 port / adapter 抽象，反而是在增加認知負擔，沒有實質回報。
判斷準則：如果系統的大多數操作是「取資料、做一點驗證、存回去」，三層夠了。如果業務邏輯複雜到需要大量單元測試、或者 infrastructure 細節（哪種 DB、哪種 queue）會頻繁改變，考慮往 Clean Architecture 或 Hexagonal 走。
下一篇 → Hexagonal Architecture
上一篇 → Clean Architecture