系統切分：架構、資料庫、API 怎麼切

是什麼？

「切分（Decomposition）」就是決定邊界——決定哪些東西該放在一起、哪些該分開。對資深 C# 開發者來說，這不是新概念：你早就在用 namespace、assembly、專案來切分程式碼。差別在於，系統層級的切分要同時切三件事：

• 架構：類別 → 模組 → 服務該怎麼分群？
• 資料庫：資料表、schema、實體 DB 該怎麼分？
• API：對外的合約該以什麼粒度暴露？

切分的唯一目標可以濃縮成兩句話：高內聚（High Cohesion）、低耦合（Low Coupling）。高內聚 = 會一起改變的東西放在一起；低耦合 = 不相關的東西不要互相依賴。所有判準都是這兩句話的推論。

切分的核心原則

切系統時，下面五個原則由強到弱排序，業務維度永遠優先於技術維度。

Bounded Context（限界上下文） 是這裡最關鍵的概念。它是 DDD（領域驅動設計）的核心：同一個名詞，在不同業務情境下其實是不同的東西，邊界就應該畫在「語意改變」的地方。

// ❌ 一個 God Class，所有情境共用一個「客戶」概念
public class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal CreditLimit { get; set; }   // 信用控管才在乎
    public string ShippingAddress { get; set; } // 出貨才在乎
    public List<Campaign> Campaigns { get; set; } // 行銷才在乎
}
 
// ✅ 依 Bounded Context 切，各情境只持有自己關心的模型
namespace Ordering   { public class Customer { public CustomerId Id; public string Name; } }
namespace Shipping   { public class Recipient { public CustomerId Id; public Address Address; } }
namespace Billing    { public class Payer { public CustomerId Id; public decimal CreditLimit; } }

注意：三個 Customer 用同一個 CustomerId 關聯，但模型本身不共用。這就是「依語意切」而非「依資料表切」。

架構怎麼切

架構切分有三個粒度層級，由輕到重：

關鍵原則：模組是縱切（依業務），分層是橫切（依技術），兩者正交。新手最常見的錯是只做橫切——把所有 Controller 放一起、所有 Repository 放一起。結果改一個「訂單」需求，要在五個技術層之間來回跳。正確做法是先依模組縱切，每個模組內部再分層。

// 模組化單體中，用 internal + 公開合約強制邊界
// Ordering 模組只暴露介面，內部實作對外不可見
namespace Ordering.Contracts  // 唯一允許跨模組引用的 assembly
{
    public interface IOrderService
    {
        Task<OrderId> PlaceOrderAsync(PlaceOrderCommand cmd);
    }
}
 
namespace Ordering.Internal   // 對其他模組 internal，無法直接 new
{
    internal sealed class OrderService : IOrderService { /* ... */ }
}

資料庫怎麼切

資料庫切分是整個系統切分中代價最高、最難回頭的決定，務必謹慎。

正規化 vs 反正規化：單體內部維持正規化（消除重複、靠外鍵維持一致性）通常是對的。但一旦跨服務邊界，外鍵就無法跨庫存在——這時被迫接受反正規化（把對方需要的欄位冗餘複製過來）。

共用 DB vs 每服務一 DB：

共用資料庫是最危險的耦合來源：兩個服務直接讀寫同一張表，等於讓對方的 schema 變成你的隱性 API。金流服務改了一個欄位型別，訂單服務就半夜爆炸。所以微服務的鐵律是「每服務一 DB，且不准跨庫直接查詢」。

何時拆表/分庫？ 給具體判準，不要憑感覺：

1. 拆表：當一張表混了兩個不同變更頻率或不同存取模式的欄位（如訂單主檔 vs 大量的訂單歷程 log）。
2. 分庫：當兩塊資料幾乎不需要交易一致性、且分屬不同 Bounded Context 時。反之，若兩塊資料每筆操作都要在同一個 transaction 內更新，這是它們屬於同一邊界的強烈訊號，硬拆只會自找麻煩。

-- 跨庫之後，原本一個 JOIN 就能拿到的資料，再也 JOIN 不到了
-- ❌ 跨服務不可行：訂單 DB 無法 JOIN 金流 DB
SELECT o.id, p.status
FROM   orders o
JOIN   payments p ON p.order_id = o.id;  -- payments 在另一個庫
 
-- ✅ 改為：訂單 DB 內冗餘一份必要的付款狀態（反正規化）
ALTER TABLE orders ADD payment_status VARCHAR(20) NOT NULL DEFAULT 'Pending';
-- 由金流服務發事件 PaymentCompleted → 訂單服務訂閱後更新此欄位（最終一致性）

API 怎麼切

API 是邊界的對外合約，切分聚焦在粒度（granularity）權衡。

• Chatty（太細）：每個欄位一支 API，前端渲染一頁要打 20 次請求，造成 N+1 與延遲累積。
• Chunky（太粗）：一支 API 回傳整個世界，傳輸肥大、難以快取、不同呼叫端各取所需卻被迫接收全部。

實務上以資源導向（Resource-oriented） 為基準：/orders/{id}、/orders/{id}/items。當「呼叫端固定需要多個資源的組合」時，引入聚合端點（Aggregation） 或 BFF（Backend for Frontend）。

BFF 的價值：前端只打一支 GET /bff/order-detail/{id}，由 BFF 在後端並行呼叫三個服務、裁剪成前端剛好需要的形狀。把 chatty 的成本從「跨網路」降到「同一資料中心內部」。

版本邊界：API 是合約，合約一旦公開就難改。用 /v1/、/v2/ 或 header 版本化隔離破壞性變更。原則：新增不破壞（加欄位）可以原地做；移除或改語意（破壞性）必須升版。

實例演練：訂單系統

走一遍。需求：使用者下單，系統處理付款、扣庫存、安排出貨。先依業務能力找出五個 Bounded Context：

邊界檢驗：為什麼這樣切？因為這五塊的變更頻率與職責各自獨立——金流規則改變不該影響商品目錄，物流商更換不該動到下單邏輯。每塊都對應一個可獨立負責的團隊與業務能力。

資料流（最終一致性）：下單不是一個大交易，而是一連串事件：

// Ordering 不直接呼叫 Shipping，而是發布事件，達成低耦合
public async Task HandleAsync(PaymentCompleted evt)
{
    var order = await _repo.GetAsync(evt.OrderId);
    order.MarkPaid();                       // 更新本地狀態（自己的 DB）
    await _repo.SaveAsync(order);
    await _bus.PublishAsync(new OrderPaid(order.Id)); // Shipping 自行訂閱
}

關鍵設計：Ordering 不知道 Shipping 的存在，只負責喊「訂單付款了」。誰要反應、怎麼反應，是訂閱者自己的事——這就是低耦合的具體實現。

常見誤區

實戰補充（Q&A）

Q：「依業務切」聽起來很抽象，我怎麼知道一個東西該不該獨立成邊界？ A：問三個問題。(1) 它有獨立的變更原因嗎？（單一職責的系統版）(2) 它能由一個團隊獨立負責嗎？（康威定律：系統結構會趨近組織結構）(3) 它的資料能由它獨佔寫入嗎？三個都「是」，就是個好邊界。

Q：那「依業務切」和我熟悉的「三層架構」衝突嗎？ A：不衝突，是正交的。三層（UI/邏輯/資料）是技術維度的橫切，業務模組是領域維度的縱切。先縱切出 Ordering、Payment 模組，每個模組內部再用三層組織。錯誤是只做橫切。

Q：什麼時候「不該」拆？ A：當兩塊資料需要強一致性交易（每筆操作都要在同一 transaction）、團隊很小（拆了沒人維運分散式系統）、或邊界尚未驗證時。拆分的代價是分散式系統的複雜度，沒有對應的收益就別拆。

Q：BFF 會不會又變成新的 God Service？ A：會，如果你把業務邏輯塞進去。BFF 只該做聚合與裁剪（aggregation & shaping），不該有業務規則。業務規則屬於各自的領域服務。BFF 是「為某個前端量身的薄殼」，一個前端一個 BFF，避免共用。

理解測驗

重點整理

切分不是一次定生死的決定，而是隨著對領域的理解加深而持續演化的過程。寧可先合（模組化單體），驗證邊界後再分（服務），也不要在不確定時就拆成難以回頭的分散式系統。