單體資料庫拆分的痛點：失去 ACID 庇護
在單體架構中，開發者習慣了利用單一資料庫的交易機制（BEGIN ... COMMIT）與跨表 JOIN 語句來快速實現複雜業務。然而當團隊規模擴大、不同模組由不同團隊獨立維護時，共用單體資料庫會成為協同開發與系統部署的巨大瓶頸。當我們將資料庫拆分，讓每個微服務擁有自己獨立的資料儲存時，首當其衝的挑戰就是跨庫交易無法再依賴傳統的本機事務。
領域邊界劃分的實務準則
拆分資料庫的第一步不是切分表格，而是梳理業務聚合根（Aggregate Root）。必須確保一個事務內強一致性變更的所有資料留在同一個服務內部；而跨服務之間的協同，則透過領域事件（Domain Events）以最終一致性的方式傳遞。 在架構設計中，我們推崇採用 Transactional Outbox 模式：微服務在寫入業務資料庫的同時，將對應的事件記錄在同庫的 outbox 表中，藉由本機交易保證事件不遺失，再由獨立程序可靠地發布至訊息匯流排（Message Broker）。
Saga 模式的編排與補償交易設計
當涉及多個微服務的長鏈路業務（如建立訂單 -> 扣減庫存 -> 扣減點數 -> 發起扣款）時，我們建議採用基於編排器（Orchestration-based Saga）的方式。編排器負責依序呼叫各微服務，若其中某一步驟失敗（如扣款餘額不足），編排器將依序觸發先前成功步驟的反向補償交易（如回補庫存、取消訂單），確保分散式系統全體狀態回歸乾淨的一致性收斂。