你很可能在技術團隊經歷過這類荒謬的資源錯配：
產品的核心業務是「跨境電商動態定價」，這套定價模型直接決定了公司每個月能否比競爭對手多擠出 4% 的毛利。然而，公司技術實力最強的兩位資深架構師，過去四個月卻在全職自幹一套「高彈性、基於 RBAC/ABAC 的分散式權限與身份驗證系統」，程式碼寫得極度抽象精美，涵蓋了十幾種設計模式與自製的快取穿透防護；
與此同時，那套攸關公司生死的定價演算法，卻因為「人力吃緊」，交由兩位剛畢業的初階工程師，在一個缺乏測試、滿是 800 行 if-else 的巨型 Controller 裡拼湊上線。每逢促銷大檔，定價邏輯必然爆出並發覆蓋與舍入誤差，造成數十萬元的毛利淨損失。
這不是單純的管理失職，而是技術團隊在「戰略架構層」的集體致盲。
軟體工程社群過去二十年談論領域驅動設計（Domain-Driven Design, DDD）時，絕大多數教學都一頭栽進戰術設計（Tactical Design）的細枝末節——討論 Aggregate 該有多大、Repository 該回傳 Entity 還是 DTO、Value Object 該如何保證不可變性。
但如果戰略方向錯了，戰術設計越完美，技術團隊把公司帶向破產的速度就越快。戰略設計的第一個核心工具——子域劃分（Subdomain Partitioning），才是決定工程資本回報率（Engineering ROI）的最高防線。
核心域 (Core Domain)
高商業差異化 × 高複雜度支撐子域 (Supporting Domain)
特異性流程 × 無溢價通用子域 (Generic Domain)
全行業共通 × 零技術溢價資源泥潭 (The Vanity Sink)
耗費數月自建身分認證中心或任務排程，而真正獲利的核心業務邏輯卻在 800 行 if-else 中裸奔。應立即計算 Churn 成本，拔除自幹模組並換成成熟服務。
核心域檢驗：「開源即倒閉」測試
DDD 將系統面臨的業務世界分為「問題空間（Problem Space）」與「解決空間（Solution Space）」。在動手寫任何一行代碼前，架構師必須在問題空間回答最冷酷的問題：這套系統裡，到底哪一部分才是公司不可被替代的真正護城河？
Eric Evans 在 DDD 經典中將子域分為三類，但教科書的定義往往過於學術。在實際工程審查中，我們可以用一條非常尖銳的判準來檢驗核心域（Core Domain）：
「開源即倒閉」測試（The Bankruptcy Open-Source Test）：
如果明天把這個模組的原始碼以 MIT 授權公開在 GitHub 上，你的公司會不會在三個月內失去商業壁壘、被競爭對手輕易複製而倒閉？
- 會倒閉： 這才是系統唯一的核心域（Core Domain）。例如 Stripe 的雷達風控引擎（Radar）、Uber 的動態撮合派單演算法、Netflix 的推薦轉碼管線。
- 不會倒閉，對手甚至懶得看： 這絕對不是核心域。對手自己去接 Clerk、Auth0 或使用 Spring Security 就能達到一模一樣的效果。這只是通用子域（Generic Subdomain）。
- 不會倒閉，但對手也用不了： 因為它高度綁定了你公司特異的線下倉儲動線或在地稅務合規規則。這是支撐子域（Supporting Subdomain）。
架構師的最高天職，不是設計全系統統一的「優雅架構」，而是無情地把 70% 以上的高階工程智力與測試精力，強行鎖死在核心域上。
三類子域的量化決策矩陣
確定了子域定位後，不同子域在工程實務上的「架構標準、團隊配置與程式碼純度」必須採取完全不同的遊戲規則。
1. 核心域（Core Domain）：自主研發 · 頂尖人才 · 零框架侵入
核心域是系統最具競爭優勢、變更頻率最高、且業務邏輯最錯綜複雜的部分。
- 工程原則： 追求極致的代碼純粹性與深模組（Deep Modules）封裝。
- 架構底線： 核心領域實體絕對嚴禁依賴外部框架。不繼承 ORM 的 Base Entity、不直接呼叫 HTTP 客戶端、不滲透 UI 欄位。所有的業務不變量（Invariants）必須能脫離資料庫與網路，在極速的單元測試中被 100% 重現。
- 團隊配置： 由團隊中最資深的架構師與領域專家（Domain Experts）結對編程，投入最周密的測試覆蓋率（包括 Property-based testing 與邊界防禦）。
2. 支撐子域（Supporting Subdomain）：夠用就好 · 拒絕過度設計 · 簡約 CRUD
支撐子域是為了讓核心域運轉而必須存在的輔助功能。市面上沒有現成的 SaaS 可以買（因為它涉及公司獨有的內部流程），但它本身不具備市場競爭力。
- 工程原則： 遵循「夠用就好（Good Enough）」原則。
- 架構底線： 嚴禁在此處套用繁複的 DDD 戰術模式。不需要搞 CQRS、不需要 Event Sourcing，更不需要刻意拆成微服務。直接使用最直觀的 Transaction Script、敏捷的 Active Record 或簡約的 CRUD 即可。
- 團隊配置： 適合指派給初中階工程師磨練業務，或在嚴格規範下交給 AI Coding Agent 自動生成基於 Schema 的全套管理後台。
3. 通用子域（Generic Subdomain）：堅決不自幹 · 採購 SaaS · 引入開源庫
通用子域是全行業所有軟體都會遇到的標準問題：身份認證、權限驗證、發送簡訊/郵件、匯出 PDF、支付對接、操作稽核紀錄。
- 工程原則： 商業成熟度極高，自研是純粹的負債。
- 架構底線： 優先採購成熟 SaaS（如 Clerk、Stripe、SendGrid）；退而求其次引入工業級開源庫。工程團隊的唯一責任是撰寫一層薄薄的防腐層（ACL）或適配器（Adapter），隔離第三方 SDK 的破壞性更新。
- 團隊配置： 指派工程師評估第三方套件的 SLA、安全性與定價模型，以最小代碼量串接完畢即停止投入。
代碼庫子域審計：用 Git Churn 揪出「為通用子域打工」
很多技術團隊並非刻意在通用子域浪費時間，而是在不知不覺中掉入「自製輪子」的沈沒成本黑洞。
如何評估現有代碼庫是否已經陷入資源錯配？我們可以透過分析 Git 的變更頻率（Churn）與程式碼的圈複雜度（Cyclomatic Complexity），對代碼庫進行客觀的戰略審計。
Git 變更熱點審計指令
在專案目錄下執行以下指令，統計過去六個月內檔案變更次數最多的前 20 個模組：
# 統計近 6 個月提交頻率最高的檔案路徑（排除 lockfile 與靜態資源）
git log --since="6 months ago" --name-only --format="" \
| grep -v -E "(pnpm-lock|package-lock|yarn.lock|dist/|\.png|\.svg)" \
| grep -v "^$" \
| sort | uniq -c | sort -nr | head -n 20交叉分析兩大危險訊號
取得變更熱點清單後，對照系統的子域劃分進行交叉檢驗：
危險訊號 A：通用子域霸佔 Churn 榜首（架構癌症）
如果排行前五名的檔案出現了 src/auth/jwt-refresher.ts、src/common/pdf-generator.ts 或 src/infra/custom-queue.ts，這代表團隊每週都在為通用基礎設施擦屁股（修復邊緣漏洞、升級暗坑、處理並發並行）。你正在用最昂貴的人力，維護一套市面上花 20 美元就能買到的基礎功能。
危險訊號 B：核心域的變更頻率與測試覆蓋率脫鉤
核心域理應是業務迭代最活躍、修改最頻繁的區域。如果在 Churn 榜首看到核心定價邏輯 src/pricing/engine.ts 變更了 80 次，但旁邊的測試檔案 src/pricing/engine.test.ts 只有 2 次提交，這代表核心護城河完全處於裸奔狀態，任何一次變更都在隨機破壞未知的業務不變量。
子域的動態演進：警惕「昨日核心」退化為「今日包袱」
戰略劃分不是一次性封頂的靜態標籤，而是動態演進的生命週期：
1. 核心域的商品化退化（Commoditization）
十年前，建立一套全文檢索與高並發模糊搜尋系統，是電商與內容平台的 Core Domain，團隊需要編寫自訂 Lucene 索引分析器；然而隨著 Elasticsearch、Algolia、Meilisearch 的普及，全文檢索在多數現代業務中已經退化為標準的 Generic Subdomain。
若架構師至今仍堅持自幹倒排索引引擎，就是典型的技術自嗨。
2. 通用域的 AI 重生（Re-differentiation）
相反地，原本被視為通用域的「客訴客服工單分類」，過去只要接 Zendesk 或簡單的規則分流即可（Generic）；但在引進大型語言模型與自研 RAG / Agentic Workflow 後，如何從客訴中精準抽取高意圖商機並自動觸發挽留策略，可能瞬間晉升為具備高度壁壘的 Core Domain。
架構師必須每半年重新審視一次系統邊界地圖： 該放手採購的立即拔除自研模組；該傾注資源的立即築起深模組防線。
落地清單：在明天站會開始的三個動作
- 畫出當前系統的問題空間地圖： 在白板上拉出 Core、Supporting、Generic 三欄，強制將所有活躍的 Git 倉庫或單體模組填入對應欄位；如果 Core 超過 2 個，直接打回票重新縮小範圍。
- 啟動第三方替代審查： 盤點 Generic 欄位中所有團隊自幹的模組，計算過去一年在修復 Bug 與維護上的總工程工時，評估替換成成熟 SaaS 或開源庫的可行性。
- 隔離核心域代碼： 將 Core Domain 模組搬遷至獨立目錄（或 Package），拔除對 ORM、Controller 與外部第三方 SDK 的直接引用，為核心業務不變量補上第一道不依賴資料庫的深模組測試防線。
在下一篇中，我們將深入戰略設計的第二個核心武器：限界上下文（Bounded Context）的切分訊號與多模型實踐，拆解如何用手術刀終結肥胖的「萬能上帝物件（God Object）」。