Quartz 5

標準資料模型

Properties1
tagsintegration, messaging, eip, message-transformation

9 min read

🎯 什麼情境該想到我

當你「要整合的應用越來越多，若兩兩之間各自做格式轉換會爆炸成 N×N，你想用一個中立格式讓每個系統只需與它互轉」的時候。

⚙️ 怎麼用（步驟 / 公式）

意圖：定義一個與任何特定應用都無關的中立資料模型，所有應用只在自己的格式與這個中立模型之間轉換，把 N×N 的點對點轉換降為 N 組轉換。

做法 / 結構要點：

  • 設計一個獨立於各應用的共通資料模型（Canonical）。
  • 每個應用在接入點放一個轉換器，負責「自身格式 ↔ 中立模型」互轉。
  • 系統之間一律以中立模型交換，應用彼此不需知道對方格式。

★★ 這是整個 EIP 型錄裡最容易被誤用、代價最大的一個模式

★ 承諾：N 個系統各自只需要「自己 ↔ 標準模型」一組轉換
        → 轉換數從 N×(N-1) 降到 2N
★ 實際發生的事：
  ① ★ 標準模型必須服務所有人 ⇒ 它成為所有欄位的聯集
  ② ★★ 沒有人擁有它 ⇒ 任何變更要協調所有團隊
  ③ ★ 每個系統的新需求都是「往標準模型加一個欄位」
  ④ ★★ 三年後：200 個欄位、每個實例 15% 有值、沒人敢刪任何一欄

★★ 這就是 內幕交易 裡「common package 為什麼一定會失敗」的企業級版本，
而且 DDD 對它有一個明確的診斷：它試圖建立一個「跨越所有 bounded context 的統一模型」，
而那在定義上就是不可能的——訂單在計費眼中是金額與稅務，在物流眼中是重量與地址，
它們是兩個概念，剛好共用一個名字。

★ 那個「N×(N-1) → 2N」的算式哪裡有問題

★ 前提是「每兩個系統都要互通」—— 而這幾乎從不成立
  實際的整合拓撲通常是稀疏的：12 個系統可能只有 15 條真實的整合路徑，
  不是 12×11 = 132 條
→ ★★ 15 條點對點轉換 vs 24 條「到標準模型」的轉換 + 一個要治理的共用模型
   → ★ 標準資料模型反而更貴

★ 判準：先數一下你真實的整合路徑有幾條。 少於 2N → 不要做。

★★ 什麼時候標準資料模型是對的

適合不適合
★ 本來就有外部標準（FHIR、ISO 20022、EDI、OpenTelemetry）★ 自己發明一個
★ 範圍窄且定義清楚（「地址」「幣別」「客戶識別」）★ 涵蓋整個業務實體（「訂單」「客戶」）
★ 有一個團隊真的擁有它（含拒絕加欄位的權力）★ 無主
★ 真的是多對多（≥ 2N 條路徑）稀疏的整合拓撲
★ 它是傳輸格式，不是任何人的內部模型被當成所有服務的領域模型

★★ 最重要的一條：標準模型只能是「傳輸格式」，不能是誰的內部模型。
一旦某個服務直接用它當領域模型，那個服務就被所有其他服務的需求綁住了。
★ 每個服務都應該在邊界上轉換成自己的模型（防腐層）。

★ 更務實的替代方案（按推薦度）

① ★★ 消費者驅動的契約（consumer-driven contracts）
   每對整合各自定義自己的契約，用 Pact 之類的工具做契約測試
   → ★ 沒有共用模型，但「誰依賴誰的什麼」是明確且可測試的

② ★ 發布者定義格式 + 每個消費者自己在邊界轉換（[[防腐層]]）
   → ★ 這是 DDD 的答案。轉換數多，但每個都由單一團隊擁有、可獨立演進

③ ★ 只標準化「共用的小片語」
   Address、Money、CustomerRef、TimeRange —— ★ 這些定義穩定、範圍窄、真的值得統一
   → ★★ 不要標準化整個 Order

④ ★ 用外部既有標準（如果有）
   → 它的治理不是你的問題，而且已經被很多人壓力測試過

★★ 如果你已經有一個腐敗的標準模型：怎麼退出

第 1 步 ★ 盤點：哪個系統實際讀了哪些欄位（★ 靠日誌／追蹤，不要靠問）
第 2 步 ★ 凍結：宣告標準模型只接受「加可選欄位」，不再接受語義變更
第 3 步 ★ 逐對拆開：把真實的整合路徑一條一條改成點對點契約
第 4 步 ★ 標準模型收斂成「小片語的集合」（Address、Money…）

★ 不要試著一次替換掉它。 這是多年的工作，而每一步都要能停在那裡。

★ 兄弟辨析

差別
正規化器★ 同樣的想法但範圍小一號（一個整合點的多個來源）
訊息轉換器單一轉換
訊息匯流排★ 常伴隨它出現——★ 而這是匯流排最貴的一部分
防腐層★★ DDD 給出的替代答案
內幕交易★ 無主共用模型的腐敗機制

🧪 我實際套用的紀錄

  • （待填）

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

  • 中立模型的設計與維護本身是持續成本，改動影響面廣。

  • 對小型、少數系統的整合可能過度設計。

  • 需治理避免中立模型逐漸長成「大雜燴」。

  • ★★ 自己發明一個涵蓋整個業務實體的標準模型，幾乎一定會腐敗成所有欄位的聯集。

  • ★★ 「N×(N-1) → 2N」的算式前提是「每兩個系統都要互通」，而那幾乎從不成立。 先數你真實的整合路徑有幾條。

  • ★★ 標準模型只能是傳輸格式，不能是任何服務的內部模型。 每個服務要在邊界轉換（防腐層）。

  • ★ 只標準化定義穩定、範圍窄的小片語（Address、Money、TimeRange），不要標準化整個 Order。

  • ★ 用外部既有標準（FHIR、ISO 20022）是唯一低風險的形態——治理不是你的問題。

  • ★ 沒有一個團隊真的擁有它（含拒絕加欄位的權力）→ 不要做。

  • ★ 退出腐敗的標準模型是多年的工作：盤點 → 凍結 → 逐對拆開 → 收斂成小片語。不要一次替換。

  • 這是 內幕交易 的企業級版本：無主的共用模型，改一個欄位要協調所有人。

🔗 相關工具

Graph View

Backlinks