ADR-0006：去領域化是硬性驗收，不是盡量
- 狀態：已採用
- 日期：2026-07
背景
這個工具箱萃取自一套真實運作的內部後台系統。原系統有很強的產業特性： 專屬術語、專屬角色、專屬流程。
萃取時的問題是：領域語意要清到什麼程度？
選項
| 選項 | 說明 |
|---|---|
| A. 只改示範資料，文件裡可以提及來源產業 | 最省事，讀者也比較有脈絡 |
| B. 全面清除，連 ADR 的背景說明都不提來源產業 | 徹底，但少了一點脈絡 |
| C. 全面清除，並寫成守衛測試 | 徹底且不會回流 |
決定
採 C：詞彙守衛測試掃描全部程式碼、示範資料、文件、ADR 與 registry，零容忍。
理由
- 示範資料會被複製貼上。 這是最實際的理由。 一旦示範裡出現特定產業的欄位，抄過去的人就會連那個產業的資料模型一起抄走—— 而且他通常不會發現，因為那些欄位「看起來很專業」。
- 提及來源會讓讀者誤判適用範圍。 只要文件說「這來自某某產業系統」， 其他產業的讀者就會開始懷疑「那我適用嗎」。
- 靠自律撐不過三個月。 趕時間的時候，直接抄原專案的範例永遠是最快的選項。
選項 A 被否決的關鍵：它會在示範資料這一層失守，而那正是傷害最大的地方。
影響
- ADR 的「背景」段落只說「來自一套內部後台系統」，不說是什麼系統。 這犧牲了一點脈絡，換來的是任何產業的讀者都不會覺得「這不是給我的」。
- 守衛測試的詞表本身就是一份「不要用什麼字」的規範， 未來新增文件時它會即時提醒。
- 這支守衛是本 repo 特有的。但它示範了一個更一般的問題： 你的設計系統有沒有偷偷綁定某個業務假設？
修訂（v0.2.1）：從「不留來源語彙」擴為「不綁死任何產業」
原本的「影響」寫著：所有示範資料統一使用中性商業情境。 而當時挑的那套「中性商業情境」， 是一整組交易型系統的欄位——單據、往來對象與其明細。
那不是中性，只是換了一個領域。 它犯的正是上面「理由 1」講的錯： 抄走示範的人會連那套資料模型一起抄走。之所以三個版本都沒被發現， 只是因為它不在守衛的詞表上——守衛只認得它被教過的那一個領域。
修訂後的規則
- 示範資料一律抽象：欄位用「項目／單位／類別／負責組別／狀態」這種不對應任何 真實業務物件的名稱，值用甲乙丙丁。長短差異只為了示範截斷與欄寬，不為了像真的。
- 詞表涵蓋四層：來源專案領域、企業系統（ERP／CRM／BPM／MES）、其他產業 （醫療／教育／金融／零售餐飲／物流／法律不動產）、英文對應詞。
- 示範資料只能有一個來源：
packages/react/src/demo/sample-data.ts。 文件與 stories 不得自行宣告資料集——每一份複本都是新領域可以溜進來的入口。 守衛見tests/demo-data.test.ts。 - 守衛自己要被驗證：比對邏輯抽成可測函式並附自我測試。 沒有這一步，「全綠」與「空轉」在報告上長得一模一樣。
代價（要說清楚）
這些詞從此在本 repo 內連舉例都不能用。想寫「假設你在做一個某某系統」會被擋下來， 要改寫成抽象敘述。這是刻意的：舉例正是領域滲進來最常見的路徑。
確有必要保留某個詞，開一則新的 ADR 討論，不要默默把它從詞表刪掉。
刻意不列的三個詞是判斷而非遺漏——主管（「印出來給主管簽名」是通用敘述）、
中位數（統計詞彙不是領域詞彙）、跟進（「需不需要跟進」是通用中文）。