軟體工程社群長期存在一個嚴重的資源浪費陷阱：一旦決定採用領域驅動設計（DDD），工程師就迫不及待地打開 IDE 建立專案目錄結構。
團隊開始熱烈討論這套系統應該分成幾層、Aggregate Root 要包含哪些 Entity、Repository 是否該返回純領域模型、Domain Event 應該用什麼機制分發。然而，在最關鍵的「系統分析端（System Analysis）」，卻沒有人問過最殘酷的商業問題：
這個我們花費頂尖資深工程師、預計耗時半年刻出來的領域模型，在整個市場的演化維度上，到底處於什麼位置？
如果答案是「市面上早已有幾十種成熟且按用量計費的 SaaS 或標準開源庫」，那麼這套寫得再精緻、測試覆蓋率再高的領域模型，在本質上依然是將昂貴的工程資本丟進水溝裡的負資產。
Eric Evans 提出的子域分類（Core Domain、Supporting Subdomain、Generic Subdomain）為我們指明了價值方向，但在實務的系統分析過程中，「什麼算核心」往往淪為產品經理與資深架構師憑直覺互擲意見的辯論大會。要讓領域邊界具備客觀的商業與架構依據，我們需要一把真正的戰略導航儀——Wardley Mapping（瓦德利地圖）。
為什麼直覺式的系統分析必然失準？
傳統需求分析在界定系統邊界時，最常犯的錯誤是**「以內部痛苦程度取代市場演化成熟度」**。
系統分析師訪談業務專家時，業務人員往往會強調「這個客服退款審核流程太痛苦了、規則多達二十條、每次人工算都出錯，這絕對是系統的核心！」工程師聽完深表贊同，隨即投入精銳部隊為其設計複雜的狀態機與規則引擎。
然而，這完全混淆了**「業務流程的繁複性」與「系統的商業差異化護城河」**。
一個功能即使規則再繁瑣、內部團隊再痛苦，如果競爭對手隨便買套 Zendesk 或 Salesforce 就能獲得相同的能力，它在戰略上就絕對不是核心域，而是標準的支撐域（Supporting Subdomain）甚至通用域（Generic Subdomain）。
如果你在系統分析端無法將「使用者的真實價值鏈」與「外部技術的成熟演進」攤開在同一張地圖上，你的系統架構就注定會被局部的雜音所綁架。
Wardley Mapping 的雙軸解構：錨定價值的座標系
Simon Wardley 發明的瓦德利地圖，本質上是一個具備**空間位置（Space）與演化動態（Movement）**的戰略地圖。它由兩個完全獨立的維度構成：
縱軸：價值鏈可見度（Value Chain Visibility）
縱軸代表組件距離最終使用者（User）的心理可見程度，從上至下展開：
- 頂層（User Needs）： 使用者直接觸碰、感知到的真實需求（例如「即時預約車輛」、「完成外幣跨國結算」）。
- 中層（Direct Capabilities）： 為了滿足頂層需求而直接支撐的業務能力（例如「司機動態撮合系統」、「即時外匯牌價計算」）。
- 底層（Underlying Infrastructure）： 支撐業務運作但使用者完全不可見的技術基石（例如關聯式資料庫、訊息隊列、身份認證管道、運算叢集）。
橫軸：演化四階段（Evolution Axis）
橫軸代表任何技術組件、業務活動或資料模型在市場競爭中的成熟度演進。所有事物都遵循嚴格的四階段生命週期：
- 1. 創生期（Genesis）： 剛被發明或探索的事物。市場極度未知，充滿高度不確定性，沒有標準，經常失敗。
- 2. 自建期（Custom-Built）： 開始展現商業價值，但市場上沒有成熟現成商品可買。組織必須自己寫代碼、刻模型，這裡正是產生商業差異化與競爭護城河的溫床。
- 3. 產品期（Product / Rental）： 市場需求確立，供應商湧現。開始出現大量成熟的套裝軟體、SaaS 平台或開源解決方案，功能趨於標準化。
- 4. 商品期（Commodity / Utility）： 演化的終局。事物演進為像自來水、電力一樣的公用基礎設施，高度標準化、即插即用、按用量計費，沒有任何客製化的必要。
當瓦德利地圖遇上 DDD：精準映射三類子域
當我們在系統分析階段，將待構建系統的所有能力分解並標註在瓦德利地圖上時，DDD 的子域劃分瞬間擁有了毫無歧義的客觀依據：
1. Custom-Built 軸心 → DDD 核心域（Core Domain）
處於「自建期」且位於價值鏈中上層的組件，就是唯一的核心域。
- 戰略特徵： 它是公司的獲利引擎與不對稱優勢，市場上買不到，也沒有成熟開源庫能完全匹配你的獨特演算法。如果把它開源，公司將直接面臨滅頂之災。
- 架構姿態： 這裡必須全力投注頂尖工程資源。使用嚴格的 Tactical DDD 實踐，設計極度乾淨的純領域模型（Domain Model），堅決杜絕被任何第三方框架或資料庫細節污染，並建立最完備的單元測試與不變量防護。
2. Product 軸心 → DDD 支撐域（Supporting Subdomain）
處於「產品期」或正從自建期向產品期過渡的業務功能，屬於支撐域。
- 戰略特徵： 業務運作不可或缺，但並不構成核心商業差異化。市場上存在現成產品，但由於公司特定的歷史包袱或組織流程，可能需要進行適度的客製化整合。
- 架構姿態： 「夠用就好（Good Enough）」，堅決反對過度架構。優先選擇市場上評分最高的 SaaS 或開源軟體進行整合。若是自行編寫代碼，應採用輕量化的 Transaction Script 或簡約架構，並在外圍建立防腐層（ACL），防止外部產品的資料模型反向侵蝕核心。
3. Commodity 軸心 → DDD 通用域（Generic Subdomain）
處於「商品/公用設施期」的所有能力，百分之百屬於通用域。
- 戰略特徵： 高度同質化、標準化。無論是電商、銀行還是社群網路，大家對身份驗證（Auth）、郵件寄送（Email）、物件存儲（Object Storage）、關聯運算（DB）的需求幾乎毫無二致。
- 架構姿態： 「堅決不自己寫一行業務邏輯代碼。」 直接訂閱 AWS S3、Stripe、Auth0、Twilio 等公用雲端服務。在此處投入人力自幹架構，是工程領導者最嚴重的瀆職。
瓦德利氣候規律：看穿架構演化與價值躍遷
瓦德利地圖最強大之處，在於揭示了商業與技術世界的氣候規律（Climatic Patterns）：
規律一：演化是單向且不可逆的（Evolution is Inevitable）。
在自由市場的競爭壓力下，地圖上的每一個組件都會持續向右移動（從 Genesis 走向 Commodity）。
十年前，自建 Redis 叢集、手刻高可用分散式隊列或搭建 Elasticsearch 搜尋引擎，可能還屬於中大型團隊展現技術實力的自建/產品期項目；而今天，它們已經徹底被 AWS Aurora、Upstash、Confluent 等雲端服務推入了 Utility 商品期。
如果在今天的系統分析會議上，架構師依然規劃耗費三個月「打造內部通用訊息中介層」，這就是在試圖逆轉演化規律。
規律二：底層商品化，價值向上躍遷（Componentisation Breeds New Systems）。
當底層組件被標準化為廉價、穩定的 Commodity 時，釋放出的生產力將催生出更高層級、原本無法實現的新創生期（Genesis）業務。
雲端運算（AWS）將伺服器商品化，才催生了 Uber 與 Netflix；基礎 LLM API 的商品化，才催生了現代各類自主 Agent 應用的爆發。
系統分析師在規劃 Bounded Context 時，必須時刻意識到：將通用能力推向 Commodity 外包，並不是節省成本的被動妥協，而是為了集中全團隊的認知帶寬，向上攻堅真正處於 Custom 階段的核心差異化能力。
實戰步驟：系統分析師的瓦德利核心域錨定法
在召集團隊開規格會議前，建議系統分析師遵循以下四步工作流：
第一步：自頂向下繪製使用者價值鏈（Anchor & Value Chain）
明確標定系統服務的最終使用者角色（Anchor），列出其核心訴求。接著往下逐層追問：「為了滿足這個需求，需要調用哪些業務能力？這些業務能力又依賴哪些底層資料與運算管道？」繪製出一條縱向的依賴樹。
第二步：水平擺放成熟演化軸（Plot Evolution）
拿著這份價值鏈清單，對每一個節點進行冷酷的客觀評估：
- 這個組件在市場上有沒有現成 SaaS？（有 → Product/Commodity）
- 市面上是否有現成產業規格協議或公認最佳實踐？（有 → Product/Commodity）
- 這個演算邏輯是否為本公司獨創且具備專利壁壘？（是 → Custom）
- 這個構想是否連市場需求都未經驗證？（是 → Genesis）
第三步：紅線阻斷——標記「自研禁區」
在 Commodity 與成熟 Product 區塊畫一條垂直紅線。所有落在紅線右側的節點，在系統分析規格書中明確標註：「只定義整合合約與 ACL 防腐介面，禁止任何內部自建方案進場。」
第四步：圈定真正的 Bounded Context
只對落在 Custom-Built 區間的核心節點，以及少數關鍵的 Supporting 節點，投入後續的領域探索工具——包括透過 Big Picture EventStorming 梳理時序事件、透過 Domain Storytelling 提煉通用語言，並最終以 Bounded Context Canvas 輸出架構合約。
下一步：從戰略定位進入全景事件探索
透過 Wardley Mapping，系統分析師已經在宏觀商業態勢上，為團隊築起了阻斷資源錯配的第一道防線，精準篩選出了值得精雕細琢的「核心域」。
然而，錨定核心域之後，我們要如何在複雜的業務流程中，讓業務專家與工程師達成深度共識，並自然辨識出潛在的系統邊界？
在下一篇中，我們將深入系統分析篇的第二大支柱：《讓業務與工程在白板前停止吵架：Big Picture EventStorming 的跨職能探索與邊界識別》，拆解如何運用橘色領域事件、時間軸梳理與紅色衝突熱點，讓系統架構在白板上自然浮現。