問題領域 vs 解決方案領域命名 (Problem vs Solution Domain Names)

問題領域 vs 解決方案領域命名 (Problem vs Solution Domain Names)Naming

好名字不只要揭露意圖，還要用讀者「已經懂」的詞彙來揭露。讀程式的人不該在腦中把你的名字翻譯成他們熟悉的概念——那次翻譯就是純粹的認知損耗。關鍵抉擇是：這個名字該借用解決方案領域（工程師的語言：演算法、設計模式、CS 術語），還是問題領域（領域專家的語言：業務概念）？答案取決於誰會來讀它。

🧠 Why It Matters

避免思維轉換是最實在的可讀性收益：讀者不該在閱讀時還得在腦中把你的變數「翻譯」成他們熟知的概念。選對方熟悉的術語，那一步翻譯就消失了。
解決方案領域名字給工程師看：像 JobQueue、OrderObserver、UserBuffer 這種名字，直接借用演算法、資料結構與設計模式的既有詞彙。看程式的都是程式設計師，用工程術語反而最快被理解——沒有人比工程師更懂 queue 是什麼。
問題領域名字給業務邏輯看：當一段程式碼承載的是商業意義，就該用領域專家的語言，像 PremiumPolicy、EscrowLedger、ClaimVoucher。這讓技術實作與商業需求對齊，領域專家也能看懂它在說什麼。
這是「揭露什麼意圖」的下一層抉擇：名字要回答「為什麼存在、做什麼、怎麼用」屬於意圖揭露命名的範疇；本頁談的是——當你要揭露那個意圖時，該挑哪一個領域的詞彙來揭露。

NOTE

判準很簡單：若沒有更貼切的問題領域名字，就用解決方案領域的名字。 因為看程式碼的人終究是程式設計師；當某個東西沒有專門的業務術語，工程師熟悉的技術詞（設計模式、演算法名）就是最不需要翻譯的選擇。

⚖️ Case Study

購物車 — 泛用容器名藏起了業務意義

// data / insert：偏解決方案領域，但只講「這是個容器」
class Cart {
  constructor() {
    this.data = []; // 泛用的資料容器，看不出裝什麼
  }

  insert(product) {
    this.data.push(product);
  }
}

data 只說「這裡有一堆資料」，insert 只說「往容器塞東西」。對一個購物車來說，這兩個名字借的是通用資料結構的詞，卻沒有回答最重要的問題：裝的是什麼？這在做什麼業務動作？讀者得自己補上「喔，這是商品、這是加入購物車」。

購物車 — 問題領域名把業務意義寫進來

// products / addProduct：問題領域，直接說出商業意義
class Cart {
  constructor() {
    this.products = []; // 明確指出裝的是商品
  }

  addProduct(product) {
    this.products.push(product);
  }
}

同樣一段邏輯，換成 products 與 addProduct 之後，名字自己就說清楚了「這是商品清單、這是把商品加進購物車」。購物車是個業務概念，讀它的人關心的是商業意義而非容器機制——所以問題領域的詞彙勝出。

工程機制 — 這裡反而該用解決方案領域名

// 一個排程元件，讀它的只有工程師：用工程術語最不需要翻譯
class JobQueue {
  constructor() {
    this.pendingJobs = [];
  }

  enqueue(job) {
    this.pendingJobs.push(job);
  }

  dequeue() {
    return this.pendingJobs.shift();
  }
}

這裡沒有現成的業務術語可借，而且會來讀它的清一色是程式設計師。JobQueue、enqueue、dequeue 借用的是每個工程師都懂的資料結構語言——硬套一個委婉的業務名反而讓熟悉 queue 的人多繞一圈。沒有更貼切的問題領域名字時，解決方案領域的名字就是正解。

TIP

先問「誰會來讀這段程式、他腦中已經有哪套詞彙」。答案是業務／領域專家，就往問題領域挑名字（PremiumPolicy）；答案是工程師、或這根本是純技術機制，就大方用解決方案領域的名字（OrderObserver、JobQueue）。目標始終一致：讓讀者不必翻譯。

WARNING

別為了「看起來專業」就把明明有業務名字的東西硬包成技術術語——把購物車的 products 改叫 data，等於丟掉現成的問題領域詞彙，逼每個讀者重新推敲它裝什麼。泛用名不是中立，是把意義的成本轉嫁給讀者。

🔑 Takeaways

好名字要用讀者「已經懂」的詞彙揭露意圖，讓他不必在腦中把你的名字翻譯成熟悉概念。
解決方案領域（JobQueue、OrderObserver）用工程師的語言——演算法、資料結構、設計模式；適合純技術機制與工程讀者。
問題領域（PremiumPolicy、EscrowLedger）用領域專家的語言，讓實作與商業需求對齊；適合承載業務意義的程式碼。
抉擇依「誰來讀」而定：沒有更貼切的業務名字時，就用解決方案領域的名字，因為讀者終究是工程師。
購物車的 data／insert → products／addProduct：業務概念用問題領域詞彙，泛用容器名只是把理解成本推給讀者。
本頁談「挑哪個領域的詞」；「名字該回答什麼」見意圖揭露命名，同概念貫徹同一詞見一詞一概念。

✍️ My Notes

No notes yet — jot your takeaways or Q&A here.

📖 Further Reading

Related concepts