五層式架構
CallIT 後端 Django 嚴格遵守的目錄分層：api → schema → service → repository → model，目的是降低耦合、便於測試。
五層職責
| 層 | 職責 | 範例工作 |
|---|---|---|
api/ | 請求接收、Routing、Response 封裝 | URL 對應 view、status code 包裝 |
schema/ | 用 Pydantic 或 Django Ninja 定義 schema，請求參數校驗 + 響應結構化 | 防 XSS、防注入、欄位型別檢查 |
service/ | 核心業務邏輯：權限校驗、狀態流轉 | APPLYING → PROCESSING 規則、角色判定 |
repository/ | 封裝所有 DB CRUD，隔離 ORM | 查/寫 Request 表、跨資料庫查詢 |
model/ | Django ORM 實體模型定義 | Request、AuditLog table 定義 |
為什麼這樣分
- api 不寫業務邏輯：避免 controller 越權做事，所有業務邏輯集中在 service
- schema 攔在最外面：所有外部輸入先校驗，保護 service 與 model
- repository 做 ORM 隔離：將來換 ORM、換 DB 不用改 service
- service 是唯一可信邏輯層：權限判定、狀態流轉只能在這寫
跟其他層的關係
api ←→ schema ←→ service ←→ repository ←→ model ←→ DB
依賴方向是單向的（上層依賴下層，不反向）：api 認得 schema/service，但 service 不認得 api。
應用場景（CallIT 特有）
- 狀態流轉：
service.transition_state(request_id, new_state)集中所有規則 - 權限驗證：
service.check_role(user, "IT")給 api 與 background task 共用 - 代申請模式：行政 / IT 角色才能呼叫
service.create_on_behalf(...)
相關概念
強連結（原文明確提及）
深入閱讀
← 回到 wiki