🎯 什麼情境該想到我
當你在盤點系統、思考「有限的最強人力與最好設計該投到哪」，想找出真正帶來商業價值、構成競爭差異的那一塊時。
⚙️ 怎麼用（步驟 / 公式）
意圖：辨識出最有商業價值、最該集中投入的核心部分，並優先照顧它。
- 盤點各子領域，問「哪一塊是我們賺錢與勝出的關鍵、別人無法輕易複製」——那就是核心子領域。
- 把最強的人力、最好的設計與最深的建模投入押在核心子領域。
- 讓最資深的領域專家與開發者長期投入這裡，持續精煉模型。
- 相對地，支撐與通用子領域盡量少投、用現成方案或外包，把資源讓給核心。
★★ 它是一個「投資決策」，不是一個技術分類
★ 三種子領域，決定你把最好的人放哪裡：
★★ 核心子領域 —— ★ 你的競爭優勢來源。★ 自己做，投入最好的人與最多的設計
★ 支撐子領域 —— ★ 你需要但不是優勢。★ 可以做得粗糙一點，或外包
★ 通用子領域 —— ★ 大家都一樣。★★ 買現成的，絕不自己寫
★★ 判準只有一句：「如果這一塊做得比對手好，客戶會因此選我們嗎？」
會 → 核心。
不會，但做不好會出事 → 支撐。
不會，而且別人早就做好了 → 通用，去買。
★★ 最常見的錯誤：把「技術上有趣」當成核心
★ 真實的誤判清單：
❌ 「我們自己寫的排程器」 → ★ 通用子領域（用 cron／Temporal）
❌ 「我們自己的 ORM／設定框架」 → ★★ 通用（而且你會維護它十年）
❌ 「我們自己寫的身分驗證」 → ★ 通用（而且★★ 自己寫的更不安全）
❌ 「我們自己的 feature flag 系統」 → ★ 通用
✅ 「我們的動態定價演算法」 → ★ 可能是核心（如果那真的是差異化）
✅ 「我們的風險評分模型」 → ★ 可能是核心
★★ 判斷方法：問業務端「如果這個功能和競爭對手一模一樣，我們會少賣嗎？」
★ 不會少賣 → 它不是核心，不管它技術上多有趣。
★★ 工程師系統性地高估自己領域的核心性，而這個偏誤有具體代價：
★ 最好的人力花在通用子領域上，而真正的核心沒有人有時間深入。
★★ 這個劃分怎麼影響具體的技術決定
| 核心子領域 | 支撐子領域 | 通用子領域 | |
|---|---|---|---|
| 誰做 | ★ 最資深的人、自己做 | 一般人力、可外包 | ★★ 買／用現成的 |
| 領域邏輯組織 | ★★ 領域模型（值得投資） | ★ 交易指令稿 | ★ 不寫 |
| 測試 | ★★ 高覆蓋、property-based | 關鍵路徑 | 整合測試 |
| 重構投資 | ★ 持續 | 夠用就好 | — |
| 文件與通用語言 | ★★ 嚴格 | 一般 | 用對方的語言 |
| 技術債容忍度 | ★★ 低 | 高 | — |
★★ 最實用的一條：核心用 領域模型，支撐用 交易指令稿。
★ 這讓「該不該引入聚合、值物件、資料對應器」有了一個客觀的判準——
不是「這樣比較乾淨」，而是「這一塊值得投資嗎」。
★★ 核心會移動，而且移動時通常沒人宣布
★ 十年前的核心，今天可能是通用：
★ 2010 年：「我們自己的推薦引擎」是核心
★ 2026 年：現成的向量檢索 + LLM 做得更好 → ★★ 它變成通用了
→ ★ 但那套自製的推薦引擎還在，而且有三個人在維護它
★ 反過來：原本的支撐可能變成核心
★ 「訂單履約」原本只是支撐 → ★ 公司改做即時配送 ⇒ ★★ 它變成核心
→ ★ 但它還是用交易指令稿寫的、沒有測試、沒有人懂
★★ 對策：每年重新盤點一次，而且要有業務端參與。
★ 這是一個產品決策，不該由工程師單方面判斷。
★ 一個具體的觸發點：★★ 當你發現「現成的方案已經比我們的好」時，
那就是把它降級成通用、並規劃遷移的時候（★ 而不是繼續改進自製的）。
★★ Go 的具體體現：程式碼結構要反映這個劃分
internal/
pricing/ ★★ 核心：領域模型、聚合、值物件、高覆蓋測試
├── price.go
├── rule.go
└── price_test.go ★ 表格測試窮舉所有定價規則
ordering/ ★ 支撐：交易指令稿 + sqlc
└── service.go
pkg/ ★ 通用：盡量薄的封裝（[[閘道]]）
├── mail/ ★ 包 SendGrid
└── auth/ ★ 包 Auth0
★★ pkg/mail 應該薄到「換供應商只改一個檔案」——
★ 而 internal/pricing 應該厚到「新人讀得懂定價規則」。
★ 一個可檢查的訊號：核心子領域的 package 有沒有 import 任何第三方？
★★ 有 → 它被基礎設施污染了（見 分離介面）。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
-
核心不是「技術最難」的部分，而是「商業上最有價值、最具差異化」的部分，別搞錯對象。
-
把頂尖人力浪費在通用子領域（如登入、通知），是常見的資源錯配。
-
核心會隨商業策略演變，需定期重新評估哪裡才是核心。
-
★★ 判準：「如果這一塊和競爭對手一模一樣，我們會少賣嗎？」 不會 → 它不是核心，不管技術上多有趣。
-
★★ 工程師系統性地高估自己領域的核心性，代價是最好的人力花在通用子領域上。
-
★★ 「我們自己寫的排程器／ORM／身分驗證／feature flag」幾乎一定是通用子領域。 自己寫的身分驗證通常更不安全。
-
★★ 核心會移動，而且移動時沒人宣布。 十年前的核心可能已經被現成方案超越，而那套自製的還有三個人在維護。
-
★ 每年重新盤點一次，而且要有業務端參與。 這是產品決策，不該由工程師單方面判斷。
-
★ 核心子領域的 package 不該 import 任何第三方——有的話它被基礎設施污染了。
-
不要用「子領域」當作偷懶的許可。 支撐子領域仍然要能運作、要有關鍵路徑的測試。