前情提要
最近在 Code Review 時遇到一個有趣的題目：
檔案上傳功能中，檔案編碼修復應該放在 Middleware 還是 UseCase？
這個問題引發了我對 Clean Architecture 分層職責的重新思考，與團隊背後的設計哲學。
問題背景
在一個採用 Clean Architecture 的專案中，我們有兩個檔案上傳功能：
- 知識庫檔案上傳 - 支援 PDF、Word、圖片等多種格式
- 合約檔案上傳 - 原始合約支援 PDF/Word，簽署後合約只支援 PDF
當前系統架構包含：
- Middleware - Express 中介軟體層
- Controller - HTTP 請求處理層
- UseCase - 業務邏輯層
- Service - 基礎設施服務層
核心問題：分層職責如何劃分？
以下邏輯應該放在哪一層？
- 檔案編碼修復 - 解決中文檔名亂碼問題 (latin1 → utf8)
- 檔案類型驗證 - 檢查 MIME type 是否符合業務需求
- 檔案大小限制 - 根據不同業務場景設定不同大小限制
- JWT Token 驗證 - 檢查使用者身份
- 檔案內容解析 - 提取 PDF/Word 文件內容
分析思路 — 職責角度
Middleware 的職責：偏向基礎設施
控制進出流程 → 例：API 請求進來先檢查 Token
過濾與轉換資料 → 例：將日期字串轉成標準格式
保護系統邊界 → 例：攔截未授權的存取
以下不舉例:
- 跨領域技術問題 (認證、編碼、錯誤處理)
- HTTP 協議相關 (請求解析、回應格式)
- 基礎設施關注點 (日誌、監控、安全)
- 與業務無關的技術細節
Use Case 的職責：偏向商業邏輯
驅動核心行為 → 例：建立一筆訂單流程
執行業務規則 → 例：檢查庫存是否足夠
協調內外資源 → 例：呼叫付款服務並更新資料庫
以下不舉例:
- 特定業務場景的規則 (不同業務有不同檔案限制)
- 領域知識驗證 (合約標題、內容檢查)
- 業務流程邏輯 (檔案處理、資料儲存)
- 動態配置的業務參數 (從環境變數讀取的業務限制)
實際案例分析
檔案編碼問題
技術問題 → 整個系統一體適用，選 Middleware ✅
細節分析:
- 這是 HTTP 上傳過程中的技術問題，不是業務邏輯
- 所有檔案上傳都需要這個處理，跨多個 UseCase
- 屬於請求處理層面的責任
檔案類型限制
業務邏輯 → 不同的上傳任務有不同限制，屬商業邏輯，選 UseCase ✅
細節分析:
- 不同業務場景有不同的檔案類型限制
- 這是領域知識，需要業務邏輯判斷
- 可能隨著業務需求變化而調整
這頭給你想
如果檔案大小限制要動態調整呢？
總結
好的架構設計不是憑感覺，而是要有明確的原則：
- Middleware = 技術基礎設施，處理 HTTP 層面的問題
- UseCase = 業務邏輯驗證，處理領域相關的規則
這種分層不只讓程式碼更好維護，也讓測試更容易撰寫，更符合單一職責原則。
下次在設計架構時，不妨問問自己：
- 這個邏輯是技術問題還是業務問題？
- 這個規則會因為業務需求變化嗎？
- 這個處理邏輯需要在多個地方重複嗎？
Clean Architecture 的精神就在於：讓業務邏輯獨立於技術細節。
(fin)