🎯 什麼情境該想到我
當你「同一個詞（例如『客戶』『商品』）在系統不同部分其實指不一樣的東西，或一個模型越長越大、概念開始互相打架」的時候。你需要明確畫出「這套模型和語言到底適用在哪個範圍」。
⚙️ 怎麼用（步驟 / 公式）
意圖：明確界定「一個特定領域模型所適用的邊界」。在界內，模型與通用語言保持嚴格一致；跨出邊界，同一個詞可以有不同意義，模型也不必相同。
做法要點：
- 找出模型會產生矛盾、或語言開始分歧的地方，那通常就是上下文邊界。
- 為每個限界上下文明確命名，界定它涵蓋哪些概念、由誰負責、對應哪塊程式碼/資料庫。
- 界內維持單一一致的模型與語言；不同上下文之間的同名概念，透過翻譯而非直接共用來連接。
- 讓邊界對應到團隊、部署單元或程式碼結構，使一致性有人守得住。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 邊界切太細會讓整合成本暴增；切太粗又會讓模型內部自相矛盾，需要權衡。
- 限界上下文是「模型適用範圍」的概念邊界，未必等於子領域（問題空間）；別把它和微服務切法直接畫等號。
- 邊界要靠團隊紀律與翻譯機制守住，否則概念會悄悄滲漏、退化成大泥球。
🔗 相關工具
- 通用語言 Ubiquitous Language（語言的一致性以此為界）
- 上下文對應 Context Map（把各限界上下文與其關係畫出來）
- 大泥球 Big Ball of Mud（邊界不清、模型混亂區塊的典型下場）
- 領域驅動設計