業務規則是軟體系統存在的理由。它們是核心中的核心，承載著幫公司賺錢或省錢的邏輯。
架構師的首要任務，就是確保這些規則保持質樸（Pristine），
不受任何外在細節（如 UI、資料庫、框架）的汙染。

一、實體 (Entities)：關鍵業務規則#

有些業務規則非常核心，即使沒有電腦系統，它們依然存在。
例如：銀行計算利息的公式。無論是用電腦算、還是行員用紙筆算，規則都是一樣的。

這類規則被稱為 「關鍵業務規則（Critical Business Rules）」，
而它們所操作的資料稱為 「關鍵業務資料（Critical Business Data）」。

實體的特徵#

我們將關鍵規則與資料綁定在一起，形成實體（Entity）。

• 純粹性： 實體是個物件，包含資料與函數
• 獨立性： 它完全不需關注資料庫、UI 或第三方框架
• 高層級： 在系統中，它是最高層級的概念（距離 I/O 最遠），因此它不依賴任何東西

二、使用案例 (Use Cases)：應用程式專屬規則#

並非所有業務規則都通用。有些規則是為自動化系統而設計的，定義了使用者如何操作系統。
這類規則稱為 「使用案例（Use Cases）」。

• 職責：
  • 控制並協調實體（Entities）的運作
  • 定義輸入資料如何轉換為輸出結果
• 依賴關係：
  • 使用案例 ➡️ 依賴 ➡️ 實體
  • 使用案例知道實體存在，但不知道使用案例的存在
  • 這符合「低層級依賴高層級」的原則（使用案例相對於實體是低層級，因它更接近 I/O）

flowchart TB
    subgraph 外部世界
        UI[UI / Web]
        DB[(Database)]
    end
    subgraph 使用案例層
        UC[Use Case<br/>應用程式專屬規則]
    end
    subgraph 實體層
        E[Entity<br/>關鍵業務規則]
    end

    UI -.-> UC
    DB -.-> UC
    UC -->|依賴| E

    style E fill:#fff3cd,stroke:#856404
    style UC fill:#f8d7da,stroke:#721c24

三、請求與回應模型 (Request & Response Models)#

使用案例需接收輸入並產生輸出。這裡有個重要架構邊界規則： 「不要讓使用案例依賴於 HTML、SQL 或 HTTP 框架。」

• 單純的資料結構： 輸入與輸出應是簡單的資料結構（Request/Response Models）
• 隔離： 這些模型不應知道 Web 的存在（例如不能繼承 HttpRequest）。
  這確保了業務規則可被用於 Web、Console 或任何未來介面上

業務規則是系統中最獨立、最可重用的程式碼。

• 實體： 代表業務的核心邏輯（不變的真理）。
• 使用案例： 代表應用程式的操作流程（自動化的劇本）。
  它們應是系統中的淨土，不應受到資料庫 SQL 或網頁 HTML 的汙染。