🎯 什麼情境該想到我
當你「兩個團隊/上下文之間有一小塊領域模型與程式碼高度相同，各做各的會重複又容易分歧」的時候。你想把這一小塊明確劃為共用，但也接受它會綁住雙方。
⚙️ 怎麼用（步驟 / 公式）
意圖：兩個團隊協議「共用一小塊領域模型與其程式碼」（包含相關的資料庫設計）。這一塊是共享核心，任何一方都不得擅自更動，改動必須雙方協調並一起測試。
做法要點：
- 明確界定共享核心的範圍——刻意保持「小」，只放真正需要共用的核心概念。
- 約定：任何一方要改共享核心，都要先與另一方溝通、取得同意。
- 每次變更後跑雙方共同的測試，確保兩邊都仍然可用。
- 定期一起檢視共享核心是否還值得共享，或該退場改成翻譯式整合。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 共享核心讓兩隊緊密耦合，需要高頻協調與良好關係；團隊若無法密切合作就別用。
- 範圍會不知不覺膨脹，要刻意守住「小」，否則等於兩隊共用一個大模型、失去獨立性。
- 若雙方演化方向漸行漸遠，硬撐共享核心會拖累彼此，此時該考慮各行其道或改用防腐層/開放主機服務。
🔗 相關工具
- 合作關係 Partnership（另一種需要高度協調的緊密關係）
- 客戶-供應商 Customer-Supplier（改用上下游而非共用的整合方式）
- 各行其道 Separate Ways（當共享不再划算時的退場選項）
- 領域驅動設計