🎯 什麼情境該想到我
當你「身為上游，有很多下游都要跟你整合，如果替每個下游各開一套特製介面會爆炸」的時候。你想提供一套公開、穩定的協定/服務，讓所有下游照同一個介面來接。
⚙️ 怎麼用（步驟 / 公式）
意圖：上游把自己的能力定義成一套公開、正式、穩定的協定或 API（一個開放的服務），供多個下游共用整合，而非為每個下游量身客製。
做法要點：
- 盤點下游共同需要的能力，設計成一套通用、對外一致的服務介面。
- 正式定義並文件化這套協定；盡量保持穩定與向後相容。
- 讓所有下游透過同一套介面整合；有特殊需求時再以擴充處理，而非另開分身。
- 常搭配發布語言作為交換的資料格式，讓協定的語彙也公開且良好定義。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 設計一套「對所有人都好」的通用協定比針對單一下游難；下游只有一個時未必值得。
- 對外協定一旦公開就得維持穩定，改動受限、演化變慢，需要版本策略。
- 若你就是想暴露自家內部模型，容易讓下游被你的模型綁死；介面應為對外設計而非內部翻版。
🔗 相關工具
- 發布語言 Published Language（常與 OHS 搭配，作為交換用的共享格式）
- 防腐層 Anticorruption Layer（下游側對應的自保翻譯層）
- 客戶-供應商 Customer-Supplier（一對一上下游關係的替代做法）
- 領域驅動設計