業務規則 (Business Rules)#

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

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

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

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

實體的特徵#

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

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

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

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

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

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

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

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

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

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