工具-通用語言

🎯 什麼情境該想到我

分工：這張是提醒卡。怎麼在 Go 型別系統中落實通用語言、三個容易漏掉的邊界、建立它的三個具體動作 → 通用語言（型錄頁）。

當工程師與業務/PM「講的是同一件事卻用不同詞」、需求翻成程式碼常失真時。

⚙️ 怎麼用

1. 建立一套團隊 + 領域專家共用的詞彙：一個概念一個名字，全員（含文件、對話、程式碼）都用它。
2. 讓程式碼直接反映這套語言：類別/方法名 = 領域術語，讀 code 像讀業務。
3. 發現詞彙模糊或衝突，就當場澄清並更新——語言的演進就是模型的演進。
4. 詞彙若在不同脈絡意義不同 → 那是要切 工具-限界上下文 的訊號。

★ 三個自我檢查問題

1. 業務人員說的詞，能在程式碼裡搜尋到嗎？ 業務說「退貨」，程式碼裡卻叫 ReverseTransaction → 語言斷了，翻譯的地方就是 bug 的溫床。
2. 同一個詞在程式碼裡只有一個意思嗎？ Account 在帳務模組是「會計科目」、在會員模組是「登入帳號」→ 這是兩個工具-限界上下文的訊號，要分開建模，而不是做一個萬用的 Account。
3. 程式碼裡有沒有業務聽不懂的詞？ OrderManager、ProcessData、status = 3 → 這些是技術詞或魔術值，業務無法確認它們對不對。

★ 最小的實踐

• 在 repo 裡放一份活的詞彙表（例如 CONTEXT.md 或 docs/glossary.md），每個詞寫一句定義與一個反例（「退貨 ≠ 取消訂單：取消發生在出貨前」）。
• code review 時把「命名與詞彙表不一致」當成正式的審查意見。
• 詞彙表要跟著討論更新；會議中出現新詞或爭議詞時，當場記下來。

🧪 我實際套用的紀錄

• 2026-07-14：（待填）

⚠️ 注意

• 通用語言要「活」在日常溝通與程式碼裡，不是一份放著長灰塵的詞彙表。

🔗 相關工具

• Skills For Real Engineers —— 通用語言的 agent 版：把行話寫進 CONTEXT.md，除了溝通一致，還讓 agent 少花 token 思考、更好導航 codebase
• 工具-限界上下文 —— 配套概念，通用語言只在一個上下文內成立，跨上下文同詞可以不同義
• 工具-有意義的命名 —— 落到程式碼那一步，通用語言的詞要原封不動出現在型別與方法名上