🎯 什麼情境該想到我
當你「想在領域層之上定義應用的操作邊界，給外部一個粗粒度的統一入口」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：以一層服務定義應用可執行的操作集合，封裝業務邏輯、協調回應、管理交易，作為對外的粗粒度 API。
做法要點：
- 每個服務方法對應一個應用使用案例（use case），供各種前端（UI、遠端呼叫、批次）共用。
- 服務層負責交易控制與跨物件協調；真正的領域邏輯仍放在領域層。
- 兩種取向：僅做委派協調的「領域外觀」，或把應用邏輯也放進來的「操作腳本」。
- 讓多種呈現層共享同一組操作，避免業務邏輯外洩到 UI。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 只有單一應用、單一前端且邏輯簡單時，多加一層是過度設計。
- 要小心別把領域邏輯堆進服務層，讓領域模型變貧血。
- 邊界劃分需依應用需求，切不好會變薄殼或肥服務。
🔗 相關工具
- 領域模型 Domain Model（服務層之下承載真正的業務邏輯）
- 交易指令稿 Transaction Script（服務層操作可用它實作）
- 企業應用架構模式