Quartz 5

工具-限界上下文

Properties1
tagssoftware, ddd, architecture, boundaries

8 min read

🎯 什麼情境該想到我

當系統/模型越長越大越糊，或發現「同一個名詞在不同部門意義不同」時。

⚙️ 怎麼用

  1. 劃出邊界：在某個邊界內，一套模型與 工具-通用語言 保持一致、無歧義。
  2. 一個詞在不同上下文意義不同 → 就該分成不同上下文（例：「商品」在銷售 vs 物流意義不同）。
  3. 用 Context Map 描述上下文之間的關係（上下游、防腐層 ACL、共享核心…）。
  4. 邊界也是團隊、部署（含微服務拆分）的自然切點。

★ 核心洞察：同一個詞，在不同上下文是不同的東西

「訂單 Order」
  銷售上下文：客戶、商品、金額、折扣          ← 關心「賣了什麼」
  倉儲上下文：SKU、數量、重量、儲位            ← 關心「拿什麼出貨」
  財務上下文：應收金額、稅、發票號碼、帳期      ← 關心「錢怎麼算」

❌ 建一個「統一的 Order 模型」滿足三方
   → ★ 30 個欄位，每一方只用 10 個，但每次改動都要三方一起 review
   → 這就是「統一模型」必然的下場

★ 限界上下文的主張是反直覺的：不要追求統一模型，而是承認「同一個名詞有多個模型」，並明確劃出邊界。
邊界內：術語一致、模型統一（這就是 工具-通用語言）。
邊界外：透過明確的轉換來往，不共用模型。

★ 怎麼找出邊界（四個實用訊號）

訊號說明
★ 語言的斷裂同一個詞在兩群人口中意思不同 → 那裡就是邊界
★ 一起改變的東西用 git log 看哪些檔案總是一起被改（見 工具-影響分析）
★ 組織結構不同團隊負責的部分天然會形成邊界（工具-康威定律）
交易一致性的需求★ 必須在同一個交易裡的東西，不該跨上下文

★ 最後一條特別重要：如果你發現「切開之後需要分散式事務」，
那八成是切錯了（見 工具-分散式事務的取捨）。

★ 上下文之間的七種關係（上下文對應 Context Map）

關係意思何時
★ 防腐層 ACL我方寫一層翻譯，把對方的模型轉成我的★ 對方模型很糟或會變時的標準做法
開放主機服務 OHS我提供一個公開的、穩定的協定給所有下游下游很多時
發布語言 PL用一個大家同意的中介格式（Protobuf schema、事件定義）配合 OHS
客戶-供應商下游能影響上游的排程同公司內
追隨者下游完全接受上游的模型，不做轉換★ 上游穩定且模型合用時（省事，但耦合）
共享核心兩個上下文共用一小塊模型與程式碼⚠️ 要非常小心，見下
各行其道完全不整合沒有整合需求時

★ 共享核心是最危險的一個：

共用的那一塊同時屬於兩個團隊，改它要兩邊同意。
它會慢慢長大，最後變成一個誰都不敢改的巨石。
→ 預設用防腐層；只在「共用的部分極小且極穩定」時才考慮共享核心。

★ 邊界 ≠ 微服務

限界上下文  = ★ 邏輯邊界（模型與語言的邊界）
微服務      = ★ 部署邊界（可獨立部署的單元）

★ 一個限界上下文「可以」是一個微服務，但不必是。
在單體裡用模組／套件劃出限界上下文，是完全正確且通常更務實的做法
——你拿到了模型的清晰，卻不用付分散式系統的代價。

★ 先在單體內劃清邊界，等邊界被驗證穩定了，再考慮拆成服務（見 工具-服務邊界與演進式拆分）。

★ 實際長什麼樣（Go）

internal/
  sales/          ← ★ 限界上下文
    order.go        type Order struct { CustomerID, Items, Discount ... }
  warehouse/      ← ★ 另一個限界上下文
    order.go        type Order struct { SKUs, Weight, Location ... }   ★ 同名不同型別，這是對的
    acl.go          ★ 防腐層：把 sales 的事件翻譯成 warehouse 的模型
  billing/
    invoice.go

★ 關鍵：warehouse 不 import sales 的型別，只透過事件或 ACL 取得它需要的資訊。
這可以用架構測試自動驗證（見 工具-好萊塢原則與依賴反轉）。

🧪 我實際套用的紀錄

  • 2026-07-14：（待填）

⚠️ 注意 / 什麼時候不適用

  • ★ 小系統不需要。整個團隊五個人、一個產品、術語一致 → 一個上下文就好。
    限界上下文解決的是「不同群人對同一個詞有不同理解」的問題——沒有這個問題就不需要它。
  • ★ 一開始就切邊界通常會切錯。你還不夠了解領域。
    → 先寫成一個模組化的單體，讓邊界在實作中浮現（見 工具-服務架構的演進與拆分）。
  • ★ 「重複」是刻意的，不是疏失。兩個上下文各有一個 Order，這不是違反 DRY——
    它們是不同的概念碰巧同名（見 工具-DRY原則 對「知識的重複 vs 程式碼的重複」的區分）。
    硬要合併才是錯的。
  • 邊界要有人守。沒有 review 紀律或架構測試，import 會慢慢穿透邊界，最後回到泥球。
  • 上下文對應要畫出來並維護。它是團隊之間的契約，不是一張畫完就丟的圖。
  • 不要為了「以後好拆微服務」而過度切割。切太細會讓每個改動都要跨好幾個上下文。

🔗 相關工具

Graph View

Backlinks