From 961ee840d77e2d4c586047de7adfa0fe5b9e17cf Mon Sep 17 00:00:00 2001 From: Zhongwei Li Date: Sun, 30 Nov 2025 08:40:24 +0800 Subject: [PATCH] Initial commit --- .claude-plugin/plugin.json | 11 + README.md | 3 + plugin.lock.json | 61 ++ skills/ddd-strategic-design/SKILL.md | 93 +++ .../references/expert-questions.md | 136 ++++ .../references/output-templates.md | 606 ++++++++++++++++++ .../references/pm-questions.md | 90 +++ .../references/user-questions.md | 169 +++++ 8 files changed, 1169 insertions(+) create mode 100644 .claude-plugin/plugin.json create mode 100644 README.md create mode 100644 plugin.lock.json create mode 100644 skills/ddd-strategic-design/SKILL.md create mode 100644 skills/ddd-strategic-design/references/expert-questions.md create mode 100644 skills/ddd-strategic-design/references/output-templates.md create mode 100644 skills/ddd-strategic-design/references/pm-questions.md create mode 100644 skills/ddd-strategic-design/references/user-questions.md diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json new file mode 100644 index 0000000..bcf611a --- /dev/null +++ b/.claude-plugin/plugin.json @@ -0,0 +1,11 @@ +{ + "name": "ddd", + "description": "Domain-Driven Design (DDD) tools and best practices", + "version": "1.0.0", + "author": { + "name": "Miles Chou" + }, + "skills": [ + "./skills" + ] +} \ No newline at end of file diff --git a/README.md b/README.md new file mode 100644 index 0000000..eecb07b --- /dev/null +++ b/README.md @@ -0,0 +1,3 @@ +# ddd + +Domain-Driven Design (DDD) tools and best practices diff --git a/plugin.lock.json b/plugin.lock.json new file mode 100644 index 0000000..3adccdb --- /dev/null +++ b/plugin.lock.json @@ -0,0 +1,61 @@ +{ + "$schema": "internal://schemas/plugin.lock.v1.json", + "pluginId": "gh:MilesChou/claude-marketplace:plugins/ddd", + "normalized": { + "repo": null, + "ref": "refs/tags/v20251128.0", + "commit": "8853045d7b6a9fefe4bc3c8861ae439a455cc5a8", + "treeHash": "d64443738f31a7d7e6329b1d2fd100a4ec4a3125be469d08fd39a44d173df6c3", + "generatedAt": "2025-11-28T10:12:07.098836Z", + "toolVersion": "publish_plugins.py@0.2.0" + }, + "origin": { + "remote": "git@github.com:zhongweili/42plugin-data.git", + "branch": "master", + "commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390", + "repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data" + }, + "manifest": { + "name": "ddd", + "description": "Domain-Driven Design (DDD) tools and best practices", + "version": "1.0.0" + }, + "content": { + "files": [ + { + "path": "README.md", + "sha256": "674fe2763c4a0e5bccf55d872fc673269db38adc7e61fdff825ed9d40ac1e37f" + }, + { + "path": ".claude-plugin/plugin.json", + "sha256": "61042509b76d1c8bc7658e5dda994942449ec705d2d0e2e61afd563787ae74d0" + }, + { + "path": "skills/ddd-strategic-design/SKILL.md", + "sha256": "4f5654f788bca33fbb6b201c3a2487c91428802c55c21b0e9083e6e1a0174f42" + }, + { + "path": "skills/ddd-strategic-design/references/expert-questions.md", + "sha256": "e2c4e39f25258c110b343a34c583fb35bc0997b8ccd0f11f47cd9dbbd7106ad5" + }, + { + "path": "skills/ddd-strategic-design/references/user-questions.md", + "sha256": "7ceefc1fdca7ddf0716dae4fb233d0c8a03a4346b29e7ea3447994f348766ce9" + }, + { + "path": "skills/ddd-strategic-design/references/pm-questions.md", + "sha256": "d3bdcf78b46a5c3262e5372e4d7332f319de6a7cfb03fc982cca0ddfc2aa6e2a" + }, + { + "path": "skills/ddd-strategic-design/references/output-templates.md", + "sha256": "47eccd86a8e9f3fa2cb74b091ab3849076e1a6117a63c32599066e67b6d9b69b" + } + ], + "dirSha256": "d64443738f31a7d7e6329b1d2fd100a4ec4a3125be469d08fd39a44d173df6c3" + }, + "security": { + "scannedAt": null, + "scannerVersion": null, + "flags": [] + } +} \ No newline at end of file diff --git a/skills/ddd-strategic-design/SKILL.md b/skills/ddd-strategic-design/SKILL.md new file mode 100644 index 0000000..98f0142 --- /dev/null +++ b/skills/ddd-strategic-design/SKILL.md @@ -0,0 +1,93 @@ +--- +name: ddd-strategic-design +description: Guide for DDD strategic design - analyzing domains through structured questioning, conducting stakeholder interviews (PM/domain experts/users), and producing Bounded Context analysis, Context Maps, and Ubiquitous Language. Use when user needs help understanding domain boundaries, planning domain interviews, or structuring DDD strategic artifacts. +--- + +# DDD Strategic Design + +## Overview + +This skill guides Domain-Driven Design strategic analysis through systematic questioning and interview planning. It helps extract domain knowledge from chaotic inputs, structure interviews with different stakeholders, and produce standard DDD strategic outputs. + +## Workflow + +### Phase 1: Input Diagnosis + +When user provides unclear or mixed information about a system: + +1. **Identify what you have**: Analyze the input type (code, documents, verbal description, requirements) +2. **Identify what's missing**: Determine gaps in domain understanding +3. **Ask clarifying questions** to establish: + - Business context and goals + - Key user roles and workflows + - System boundaries and constraints + - Existing pain points or complexity + +**Questioning principles:** +- Start broad, then narrow down +- Ask one question at a time to avoid overwhelming +- Use "why" to uncover business rules +- Use "what if" to discover edge cases +- Use "who" to identify stakeholders and their needs + +### Phase 2: Domain Exploration + +Guide domain discovery through progressive questioning: + +1. **Identify core business concepts**: What are the key entities, events, and processes? +2. **Find natural boundaries**: Where do terms mean different things? Where do teams/processes separate? +3. **Discover business rules**: What constraints, validations, or policies exist? +4. **Map workflows**: How do different parts of the system interact? + +**Red flags for context boundaries:** +- Same term with different meanings in different areas +- Different teams owning different parts of workflow +- Independent change cycles +- Different data consistency requirements + +### Phase 3: Interview Planning + +When user needs to interview stakeholders, generate targeted question sets: + +**For Product Managers** - See `references/pm-questions.md`: +- Business goals and priorities +- Success metrics +- Roadmap and constraints + +**For Domain Experts** - See `references/expert-questions.md`: +- Business rules and terminology +- Edge cases and exceptions +- Domain constraints and invariants + +**For End Users** - See `references/user-questions.md`: +- Actual workflows and pain points +- Task sequences and decision points +- Desired outcomes + +### Phase 4: Synthesis and Output + +Transform gathered knowledge into DDD artifacts: + +1. **Bounded Context Analysis** - Document each context's purpose, boundaries, and responsibilities +2. **Context Map** - Visualize relationships between contexts using standard DDD patterns +3. **Ubiquitous Language** - Create glossary of domain terms with precise definitions + +See `references/output-templates.md` for detailed formats and examples. + +## Iterative Refinement + +Domain understanding evolves. After initial analysis: +- Identify remaining ambiguities +- Suggest follow-up questions +- Validate assumptions with stakeholders +- Refine boundaries based on new insights + +## References + +This skill includes interview question templates and output format guides: + +- `references/pm-questions.md` - Question framework for Product Manager interviews +- `references/expert-questions.md` - Question framework for Domain Expert interviews +- `references/user-questions.md` - Question framework for End User interviews +- `references/output-templates.md` - Templates for Bounded Context analysis, Context Map, and Ubiquitous Language + diff --git a/skills/ddd-strategic-design/references/expert-questions.md b/skills/ddd-strategic-design/references/expert-questions.md new file mode 100644 index 0000000..51fb3f3 --- /dev/null +++ b/skills/ddd-strategic-design/references/expert-questions.md @@ -0,0 +1,136 @@ +# Domain Expert Interview Questions + +領域專家訪談的目標是挖掘深層的業務規則、術語定義、以及複雜的領域邏輯。這些知識是建立 Ubiquitous Language 和識別 Bounded Context 邊界的關鍵。 + +## Phase 1: 術語與概念澄清 + +**目的：建立精確的領域詞彙，發現同名異義或異名同義的情況** + +1. 在你的工作中，最常用的專業術語有哪些？ +2. [針對特定術語] 這個詞在你的領域中具體是什麼意思？ +3. 有沒有同一個詞在不同情境下意思不一樣的情況？ +4. 有沒有外行人容易誤解的術語？ +5. 有哪些術語是業界標準，哪些是公司內部特有的？ + +**追問技巧：** +- "你能舉個具體的例子嗎？" - 用實例驗證理解 +- "這個術語和 [另一個相似術語] 有什麼不同？" - 區分細微差異 +- "新人常常會把這個詞理解錯成什麼？" - 找出常見誤區 + +## Phase 2: 業務規則與不變條件 + +**目的：挖掘核心業務規則、invariants、以及領域約束** + +1. 在你的領域中，有哪些「絕對不能違反」的規則？ +2. 什麼情況下 [某個操作] 是不被允許的？ +3. 如果 [某個規則] 被打破，會發生什麼問題？ +4. 這些規則的來源是什麼？（法規、業務慣例、技術限制？） +5. 這些規則會改變嗎？什麼情況下會改變？ + +**追問技巧：** +- "為什麼會有這條規則？" - 理解規則背後的原因 +- "這條規則有例外嗎？" - 發現特殊情況 +- "如果不遵守這個規則，誰會受影響？" - 理解影響範圍 + +## Phase 3: 領域事件與狀態轉換 + +**目的：識別關鍵的領域事件，理解實體的生命週期和狀態機** + +1. 在你的日常工作中，有哪些重要的「事情發生了」的時刻？ +2. 當 [某個事件] 發生時，接下來通常會發生什麼？ +3. [某個實體] 會經歷哪些狀態？如何從一個狀態轉換到另一個？ +4. 什麼情況下狀態轉換會失敗？ +5. 有哪些事件是需要立即通知其他人或系統的？ + +**追問技巧：** +- "這個事件可以被撤銷嗎？" - 理解可逆性 +- "這個事件的發生順序重要嗎？" - 識別時序約束 +- "如果這個事件沒有被記錄會怎樣？" - 理解事件的重要性 + +## Phase 4: 計算與決策邏輯 + +**目的：理解複雜的計算公式、評分機制、或決策流程** + +1. [某個值] 是如何計算出來的？ +2. 在做 [某個決策] 時，你會考慮哪些因素？ +3. 有沒有一些經驗法則或啟發式方法？ +4. 這個計算 / 決策有精確的公式嗎，還是依賴專家判斷？ +5. 什麼情況下計算結果需要人工覆核？ + +**追問技巧：** +- "能否用一個具體的例子走一遍計算過程？" - 驗證理解 +- "這個公式中哪些參數最關鍵？" - 識別核心因素 +- "有沒有邊界值或特殊情況需要特別處理？" - 發現邊界條件 + +## Phase 5: 異常情況與邊界案例 + +**目的：發現容易被忽略的特殊情況，這些往往揭示了隱藏的複雜度** + +1. 在實際工作中，有哪些「例外情況」需要特殊處理？ +2. 最讓你頭痛的邊界案例是什麼？ +3. 新手最容易在哪裡犯錯？ +4. 有沒有一些「理論上不該發生但實際上會發生」的情況？ +5. 當系統出現錯誤時，你如何判斷和處理？ + +**追問技巧：** +- "這種情況多久會遇到一次？" - 評估頻率 +- "處理這種情況的標準流程是什麼？" - 理解處理機制 +- "如果處理不當會有什麼風險？" - 評估嚴重性 + +## Phase 6: 資料與資訊流 + +**目的：理解資料如何流動，哪些資料是權威來源，哪些是衍生的** + +1. 這份資料的權威來源 (Source of Truth) 是哪裡？ +2. 這份資料會同步到哪些地方？ +3. 資料的時效性要求是什麼？（即時、近即時、最終一致？） +4. 如果兩個地方的資料不一致，以哪個為準？ +5. 資料的完整性和準確性如何驗證？ + +**追問技巧：** +- "這份資料可以被修改嗎？什麼情況下可以修改？" - 理解可變性 +- "這份資料需要保存多久？" - 理解生命週期 +- "誰有權限存取 / 修改這份資料？" - 理解權限邊界 + +## Phase 7: 與其他領域的互動 + +**目的：識別 Bounded Context 之間的邊界和整合點** + +1. 你的工作需要和哪些其他部門 / 團隊協作？ +2. 你需要從其他系統獲取哪些資訊？ +3. 你產出的資訊會被誰使用？ +4. 在協作過程中，有沒有遇到「他們用的詞和我們不一樣」的情況？ +5. 跨部門協作時，最常遇到的問題是什麼？ + +**追問技巧：** +- "你們之間是如何交接資訊的？" - 理解整合方式 +- "對方提供的資訊格式符合你的需求嗎？" - 發現適配問題 +- "如果對方的系統出問題，你這邊會受什麼影響？" - 理解耦合度 + +## Phase 8: 時間與並發考量 + +**目的：理解時間相關的業務規則和並發情況下的處理邏輯** + +1. 這個操作有時間限制嗎？（截止日期、有效期限、時效性？） +2. 如果兩個人同時進行 [某個操作]，會發生什麼？ +3. 歷史資料的處理方式是什麼？需要追溯修改嗎？ +4. 有沒有「生效日期」或「排程執行」的概念？ +5. 時區或營業時間會影響業務邏輯嗎？ + +**追問技巧：** +- "如果操作超過時限會怎樣？" - 理解超時處理 +- "能否回到過去的某個時間點查看狀態？" - 理解歷史追蹤需求 +- "這個操作可以被排程延後執行嗎？" - 理解時序彈性 + +## 訪談後整理重點 + +根據領域專家訪談，應該能整理出： + +1. **Ubiquitous Language 詞彙表** - 精確定義的領域術語 +2. **核心業務規則清單** - invariants 和約束條件 +3. **領域事件目錄** - 關鍵的業務事件和觸發條件 +4. **狀態機圖** - 重要實體的狀態轉換 +5. **異常處理機制** - 邊界案例和例外情況 +6. **Context 邊界訊號** - 術語衝突、團隊邊界、資料權威來源的差異 + +記住：領域專家提供的是深度知識，但可能缺乏全局視角。需要與 PM 和用戶訪談結合，才能建立完整的領域理解。 diff --git a/skills/ddd-strategic-design/references/output-templates.md b/skills/ddd-strategic-design/references/output-templates.md new file mode 100644 index 0000000..095183c --- /dev/null +++ b/skills/ddd-strategic-design/references/output-templates.md @@ -0,0 +1,606 @@ +# DDD Strategic Design Output Templates + +本文件提供三種核心 DDD 戰略設計產出物的標準格式和範例。 + +--- + +## 1. Bounded Context Analysis + +### 目的 +記錄每個 Bounded Context 的職責、邊界、以及與其他 Context 的關係。 + +### 格式 + +```markdown +# Bounded Context: [Context 名稱] + +## 概述 +[1-2 段描述這個 Context 的核心職責和存在理由] + +## 業務能力 +- [此 Context 提供的核心業務能力 1] +- [此 Context 提供的核心業務能力 2] +- [此 Context 提供的核心業務能力 3] + +## 領域分類 +- **類型**: Core Domain / Supporting Subdomain / Generic Subdomain +- **戰略重要性**: High / Medium / Low +- **複雜度**: High / Medium / Low + +## Ubiquitous Language (核心術語) +| 術語 | 定義 | 備註 | +|------|------|------| +| [術語 1] | [在此 Context 中的精確定義] | [與其他 Context 的差異或特殊說明] | +| [術語 2] | [在此 Context 中的精確定義] | [與其他 Context 的差異或特殊說明] | + +## 核心實體與聚合 +- **[聚合名稱 1]**: [簡述聚合根和主要實體] +- **[聚合名稱 2]**: [簡述聚合根和主要實體] + +## 關鍵領域事件 +- [領域事件 1]: [發生時機和意義] +- [領域事件 2]: [發生時機和意義] + +## 邊界與職責 +### 包含的職責 +- [明確屬於此 Context 的職責 1] +- [明確屬於此 Context 的職責 2] + +### 排除的職責 (不負責) +- [明確不屬於此 Context 的職責 1] +- [明確不屬於此 Context 的職責 2] + +## 對外整合點 +| 整合對象 | 整合方式 | 資料流向 | 說明 | +|----------|----------|----------|------| +| [其他 Context] | [ACL/OHS/etc] | [雙向/單向] | [整合目的和內容] | + +## 團隊與所有權 +- **負責團隊**: [團隊名稱] +- **主要聯絡人**: [姓名/角色] +- **決策權**: [此 Context 的設計決策由誰負責] + +## 技術考量 +- **主要技術棧**: [程式語言、框架] +- **資料儲存**: [資料庫類型] +- **部署方式**: [獨立服務 / 模組 / 函式庫] + +## 演化歷史與未來規劃 +- **當前狀態**: [現況描述] +- **已知問題**: [技術債或設計問題] +- **未來規劃**: [預期的變化或改善方向] +``` + +### 範例 + +```markdown +# Bounded Context: Order Management (訂單管理) + +## 概述 +Order Management Context 負責處理客戶訂單的完整生命週期，從訂單建立、驗證、到履行協調。這是電商平台的核心 Context，直接影響營收和客戶體驗。 + +## 業務能力 +- 接收和驗證客戶訂單 +- 計算訂單總價 (含稅、折扣、運費) +- 協調庫存預留和付款處理 +- 追蹤訂單狀態和進度 +- 處理訂單修改和取消 + +## 領域分類 +- **類型**: Core Domain +- **戰略重要性**: High +- **複雜度**: High + +## Ubiquitous Language (核心術語) +| 術語 | 定義 | 備註 | +|------|------|------| +| Order (訂單) | 客戶購買意圖的正式記錄，包含商品、數量、價格和配送資訊 | 不同於 Cart (購物車)，Order 代表已承諾的交易 | +| Order Line (訂單項目) | 訂單中的單一商品項目，包含 SKU、數量、單價 | 可獨立取消或退貨 | +| Order Status (訂單狀態) | 訂單當前所處的階段 | 可能的值: Pending, Confirmed, Shipped, Delivered, Cancelled | +| Fulfillment (履行) | 完成訂單的實體流程，包含撿貨、包裝、出貨 | 由 Warehouse Context 負責實際執行 | + +## 核心實體與聚合 +- **Order Aggregate**: Order (聚合根)、OrderLine、ShippingAddress、BillingAddress +- **Pricing Aggregate**: Price、Discount、TaxRate + +## 關鍵領域事件 +- OrderPlaced: 訂單建立時發布，觸發庫存預留和付款流程 +- OrderConfirmed: 付款成功後發布，觸發履行流程 +- OrderCancelled: 訂單取消時發布，釋放已預留資源 + +## 邊界與職責 +### 包含的職責 +- 訂單資料的完整性和一致性 +- 訂單狀態的生命週期管理 +- 訂單相關的業務規則驗證 +- 訂單事件的發布 + +### 排除的職責 (不負責) +- 實際的庫存扣減 (由 Inventory Context 負責) +- 付款交易處理 (由 Payment Context 負責) +- 物流配送執行 (由 Warehouse Context 負責) +- 商品資訊維護 (由 Catalog Context 負責) + +## 對外整合點 +| 整合對象 | 整合方式 | 資料流向 | 說明 | +|----------|----------|----------|------| +| Inventory Context | Event-Driven | 雙向 | 請求庫存預留，接收庫存確認 | +| Payment Context | ACL | 單向 (Order→Payment) | 發起付款請求 | +| Warehouse Context | OHS | 單向 (Order→Warehouse) | 下達履行指令 | +| Catalog Context | ACL | 單向 (Order→Catalog) | 查詢商品資訊和價格 | + +## 團隊與所有權 +- **負責團隊**: 交易核心團隊 (Transaction Core Team) +- **主要聯絡人**: Alice Chen (Tech Lead) +- **決策權**: 訂單領域模型由交易核心團隊決策，需與產品團隊協調業務需求 + +## 技術考量 +- **主要技術棧**: Java 17, Spring Boot, PostgreSQL +- **資料儲存**: PostgreSQL (交易資料), Redis (快取) +- **部署方式**: 獨立微服務，容器化部署 + +## 演化歷史與未來規劃 +- **當前狀態**: 已上線運行 2 年，穩定支援日均 10 萬筆訂單 +- **已知問題**: 訂單修改邏輯過於複雜，有重構需求 +- **未來規劃**: 考慮引入 Event Sourcing 來更好地追蹤訂單變更歷史 +``` + +--- + +## 2. Context Map (上下文映射圖) + +### 目的 +視覺化展示 Bounded Contexts 之間的關係和整合模式。 + +### Context Mapping Patterns (關係模式) + +#### 團隊協作模式 +- **Partnership (夥伴關係)**: 兩個團隊緊密合作，共同演化 +- **Shared Kernel (共享核心)**: 兩個 Context 共享部分領域模型 +- **Customer-Supplier (客戶-供應商)**: 下游團隊依賴上游團隊提供的介面 + +#### 獨立演化模式 +- **Conformist (遵從者)**: 下游完全接受上游的模型，無議價能力 +- **Anticorruption Layer (防腐層 - ACL)**: 下游建立轉換層來隔離上游影響 +- **Open Host Service (開放主機服務 - OHS)**: 上游提供標準化的公開 API +- **Published Language (公開語言)**: 使用行業標準格式 (如 JSON Schema) + +#### 特殊模式 +- **Separate Ways (分道揚鑣)**: 兩個 Context 完全獨立，無整合 +- **Big Ball of Mud (大泥球)**: 混亂無邊界的遺留系統 + +### 文字格式 + +```markdown +# Context Map: [系統名稱] + +## Contexts Overview + +### [Context A] +- **類型**: Core Domain +- **團隊**: [團隊名稱] + +### [Context B] +- **類型**: Supporting Subdomain +- **團隊**: [團隊名稱] + +## Context Relationships + +### [Context A] → [Context B]: [關係模式] +- **方向**: A 依賴 B / B 依賴 A / 雙向依賴 +- **整合方式**: REST API / Event Bus / Shared Database / RPC +- **資料流**: [什麼資料在兩者間流動] +- **說明**: [為什麼選擇這種關係模式] + +### [Context B] ← [Context C]: [關係模式] +- **方向**: ... +- **整合方式**: ... +- **資料流**: ... +- **說明**: ... +``` + +### 圖形格式 (Mermaid) + +```mermaid +graph TB + subgraph "Core Domain" + OrderMgmt[Order Management] + end + + subgraph "Supporting Subdomains" + Inventory[Inventory] + Payment[Payment] + Warehouse[Warehouse] + end + + subgraph "Generic Subdomains" + Notification[Notification] + Catalog[Catalog] + end + + OrderMgmt -->|ACL| Payment + OrderMgmt -->|Event-Driven| Inventory + OrderMgmt -->|OHS| Warehouse + OrderMgmt -->|ACL| Catalog + Warehouse -->|Partnership| Inventory + OrderMgmt -.->|Conformist| Notification + + classDef core fill:#f96,stroke:#333,stroke-width:4px + classDef supporting fill:#9cf,stroke:#333,stroke-width:2px + classDef generic fill:#cfc,stroke:#333,stroke-width:1px + + class OrderMgmt core + class Inventory,Payment,Warehouse supporting + class Notification,Catalog generic +``` + +### 範例 + +```markdown +# Context Map: E-Commerce Platform + +## Contexts Overview + +### Order Management (訂單管理) +- **類型**: Core Domain +- **團隊**: Transaction Core Team +- **職責**: 訂單生命週期管理 + +### Inventory (庫存管理) +- **類型**: Supporting Subdomain +- **團隊**: Supply Chain Team +- **職責**: 庫存追蹤和預留 + +### Payment (付款處理) +- **類型**: Supporting Subdomain +- **團隊**: Payment Team +- **職責**: 金流處理和對帳 + +### Warehouse (倉儲管理) +- **類型**: Supporting Subdomain +- **團隊**: Operations Team +- **職責**: 訂單履行和物流 + +### Catalog (商品目錄) +- **類型**: Generic Subdomain +- **團隊**: Content Team +- **職責**: 商品資訊管理 + +### Notification (通知服務) +- **類型**: Generic Subdomain +- **團隊**: Platform Team +- **職責**: 郵件、簡訊、推播通知 + +## Context Relationships + +### Order Management → Inventory: Event-Driven (事件驅動) +- **方向**: 雙向依賴 +- **整合方式**: Message Queue (RabbitMQ) +- **資料流**: + - Order→Inventory: InventoryReservationRequested 事件 + - Inventory→Order: InventoryReserved / InventoryUnavailable 事件 +- **說明**: 使用事件驅動確保庫存預留的非同步處理，避免阻塞訂單建立流程 + +### Order Management → Payment: Anticorruption Layer (防腐層) +- **方向**: Order 依賴 Payment +- **整合方式**: REST API with ACL +- **資料流**: 付款請求和結果查詢 +- **說明**: Payment Context 的模型較複雜且經常變動，使用 ACL 隔離變化，Order Context 內部使用簡化的付款模型 + +### Order Management → Warehouse: Open Host Service (開放主機服務) +- **方向**: Order 依賴 Warehouse +- **整合方式**: Warehouse 提供標準化 REST API +- **資料流**: 履行指令 (Fulfillment Order) +- **說明**: Warehouse 作為多個上游 Context 的服務提供者，提供穩定的公開介面 + +### Order Management → Catalog: Anticorruption Layer (防腐層) +- **方向**: Order 依賴 Catalog +- **整合方式**: GraphQL API with ACL +- **資料流**: 商品資訊查詢 (價格、庫存狀態) +- **說明**: Catalog 的資料模型面向內容管理，與 Order 的交易模型不同，使用 ACL 轉換 + +### Warehouse ↔ Inventory: Partnership (夥伴關係) +- **方向**: 雙向緊密協作 +- **整合方式**: Direct API calls + Shared Events +- **資料流**: 實體庫存變動、撿貨確認 +- **說明**: 兩個團隊共同負責實體庫存的準確性，需要緊密協作和共同演化 + +### Order Management → Notification: Conformist (遵從者) +- **方向**: Order 依賴 Notification +- **整合方式**: Event Bus (單向) +- **資料流**: 訂單狀態通知請求 +- **說明**: Notification 是通用服務，Order 接受其定義的事件格式，不需要轉換層 + +## Strategic Decisions + +1. **為何 Order 與 Inventory 使用事件驅動？** + - 庫存預留可能需要等待，不適合同步 API + - 解耦兩個 Context，允許獨立擴展 + +2. **為何需要多個 ACL？** + - Payment 和 Catalog 的模型差異大，直接使用會污染 Order 的領域模型 + - ACL 提供穩定的內部介面，隔離外部變化 + +3. **Warehouse 為何選擇 OHS？** + - 多個上游 Context 需要倉儲服務 (Order, Return, Transfer) + - 標準化介面降低維護成本 +``` + +--- + +## 3. Ubiquitous Language Glossary (統一語言詞彙表) + +### 目的 +記錄整個系統或特定 Bounded Context 內的精確術語定義，確保團隊溝通無歧義。 + +### 格式 + +```markdown +# Ubiquitous Language: [Context 或系統名稱] + +## 如何使用本詞彙表 +- **範圍**: 本詞彙表涵蓋 [具體範圍] +- **維護**: 由 [負責人/團隊] 維護 +- **更新頻率**: 每當新增或修改術語時立即更新 + +--- + +## [分類 1: 例如「核心實體」] + +### [術語 1] +- **英文**: [English Term] +- **定義**: [清晰、無歧義的定義] +- **範例**: [實際使用的例子] +- **關聯術語**: [相關的其他術語] +- **注意事項**: [常見誤解或與其他 Context 的差異] + +### [術語 2] +- **英文**: [English Term] +- **定義**: ... + +## [分類 2: 例如「狀態與生命週期」] + +... + +## [分類 3: 例如「業務規則與約束」] + +... +``` + +### 範例 + +```markdown +# Ubiquitous Language: Order Management Context + +## 如何使用本詞彙表 +- **範圍**: Order Management Bounded Context 內使用的所有領域術語 +- **維護**: 由 Transaction Core Team 維護 +- **更新頻率**: 每當新增或修改術語時立即更新 +- **版本**: v2.3 (2025-10-20) + +--- + +## 核心實體 + +### Order (訂單) +- **英文**: Order +- **定義**: 客戶向系統提交的購買承諾，包含一個或多個商品項目、配送資訊、和付款資訊。訂單一旦建立，即產生履行義務。 +- **範例**: "訂單 #ORD-20251020-00123 包含 3 個訂單項目" +- **關聯術語**: Order Line, Order Status, Fulfillment +- **注意事項**: + - 不同於 Cart (購物車): Cart 是暫時的、可隨意修改的，Order 是正式的承諾 + - 不同於 Fulfillment Context 的 "Fulfillment Order": 那是倉儲執行視角，我們的 Order 是交易視角 + +### Order Line (訂單項目) +- **英文**: Order Line / Line Item +- **定義**: 訂單中的單一商品項目，包含 SKU、數量、單價、和小計。Order Line 是訂單的組成部分,不能獨立存在。 +- **範例**: "訂單項目: SKU-12345 × 2,單價 NT$500,小計 NT$1000" +- **關聯術語**: Order, SKU, Quantity +- **注意事項**: + - 可以單獨取消或退貨,但仍屬於父訂單 + - 價格在 Order Line 建立時鎖定,不受之後的 Catalog 價格變動影響 + +### Customer (客戶) +- **英文**: Customer +- **定義**: 在系統中下訂單的自然人或法人。在 Order Context 中,我們只關心客戶的識別 (Customer ID) 和聯絡資訊,不處理客戶資料的完整管理。 +- **範例**: "客戶 #CUST-789 下了新訂單" +- **關聯術語**: Order, Shipping Address, Billing Address +- **注意事項**: + - 客戶的詳細資料 (會員等級、偏好等) 由 Customer Context 管理 + - 我們只儲存訂單所需的最小客戶資訊副本 + +--- + +## 狀態與生命週期 + +### Order Status (訂單狀態) +- **英文**: Order Status +- **定義**: 訂單在其生命週期中的當前階段。狀態轉換遵循特定的業務規則,不可隨意跳躍。 +- **可能的值**: + - `Pending`: 訂單已建立,等待付款確認 + - `Confirmed`: 付款成功,訂單確認 + - `Preparing`: 倉儲正在準備出貨 + - `Shipped`: 已出貨 + - `Delivered`: 已送達 + - `Cancelled`: 已取消 + - `Refunded`: 已退款 +- **範例**: "訂單狀態從 Confirmed 轉換為 Preparing" +- **關聯術語**: Order, Order Lifecycle, Domain Events +- **注意事項**: + - 狀態轉換會發布 Domain Events + - 某些狀態轉換是不可逆的 (如 Delivered → Pending) + +### Fulfillment Status (履行狀態) +- **英文**: Fulfillment Status +- **定義**: 訂單的實體履行進度,獨立於 Order Status 追蹤。這是從 Warehouse Context 同步過來的資訊。 +- **可能的值**: `NotStarted`, `InProgress`, `Completed`, `Failed` +- **範例**: "訂單的履行狀態為 InProgress" +- **關聯術語**: Order Status, Warehouse Context +- **注意事項**: + - Fulfillment Status 由 Warehouse 控制,我們只讀取 + - Order Status 和 Fulfillment Status 不一定同步更新 + +--- + +## 業務規則與約束 + +### Order Modification Window (訂單修改時間窗) +- **英文**: Order Modification Window +- **定義**: 訂單確認後,客戶可以修改訂單內容的時間限制。超過此時間窗後,修改需要更複雜的流程。 +- **規則**: 訂單確認後 30 分鐘內可自由修改,超過後需客服介入 +- **範例**: "此訂單已超過修改時間窗,無法自動修改" +- **關聯術語**: Order Status, Order Confirmed +- **注意事項**: 修改時間窗不適用於取消操作,取消有獨立的規則 + +### Minimum Order Amount (最低訂單金額) +- **英文**: Minimum Order Amount / MOA +- **定義**: 系統接受的訂單總額下限。低於此金額的訂單無法提交。 +- **規則**: 一般客戶最低 NT$100,VIP 客戶無限制 +- **範例**: "訂單金額 NT$80 低於最低訂單金額,無法提交" +- **關聯術語**: Order Total, Customer Type +- **注意事項**: 不含運費和手續費 + +### Inventory Reservation Timeout (庫存預留逾時) +- **英文**: Inventory Reservation Timeout +- **定義**: 訂單建立後,系統為其預留庫存的有效時間。超時後,如果訂單仍未付款,預留將被釋放。 +- **規則**: 預留時間為 15 分鐘 +- **範例**: "訂單 #ORD-123 的庫存預留已逾時" +- **關聯術語**: Order Status, Inventory Context +- **注意事項**: 逾時後訂單狀態變為 Expired,客戶需要重新下單 + +--- + +## 領域事件 + +### OrderPlaced +- **英文**: Order Placed Event +- **定義**: 當客戶成功提交訂單時發布的事件。這是訂單生命週期的起點。 +- **觸發時機**: Order 聚合建立並持久化後 +- **包含資料**: Order ID, Customer ID, Order Lines, Total Amount, Timestamp +- **訂閱者**: Inventory Context (庫存預留), Payment Context (發起付款), Notification Context (發送確認信) +- **範例**: `OrderPlaced { orderId: "ORD-123", customerId: "CUST-789", totalAmount: 1500 }` + +### OrderConfirmed +- **英文**: Order Confirmed Event +- **定義**: 當訂單付款成功,訂單正式確認時發布的事件。 +- **觸發時機**: Payment Context 通知付款成功,Order 狀態更新為 Confirmed 後 +- **包含資料**: Order ID, Payment ID, Confirmed At +- **訂閱者**: Warehouse Context (開始履行), Notification Context (通知客戶) +- **範例**: `OrderConfirmed { orderId: "ORD-123", paymentId: "PAY-456", confirmedAt: "2025-10-20T10:30:00Z" }` + +### OrderCancelled +- **英文**: Order Cancelled Event +- **定義**: 當訂單被取消時發布的事件,無論是客戶主動取消或系統取消。 +- **觸發時機**: Order 狀態更新為 Cancelled 後 +- **包含資料**: Order ID, Cancellation Reason, Cancelled By, Cancelled At +- **訂閱者**: Inventory Context (釋放預留), Payment Context (退款處理), Notification Context (通知客戶) +- **範例**: `OrderCancelled { orderId: "ORD-123", reason: "Customer Request", cancelledBy: "CUST-789" }` + +--- + +## 值物件 (Value Objects) + +### Money (金額) +- **英文**: Money +- **定義**: 表示貨幣金額的值物件,包含數值和幣別。 +- **屬性**: `amount` (Decimal), `currency` (String, ISO 4217 code) +- **範例**: `Money { amount: 1500.00, currency: "TWD" }` +- **注意事項**: + - 金額計算必須考慮精度,使用 Decimal 而非 Float + - 不同幣別不可直接相加,需要匯率轉換 + +### Address (地址) +- **英文**: Address +- **定義**: 表示實體地址的值物件,用於配送和帳單地址。 +- **屬性**: + - `recipientName`: 收件人姓名 + - `phone`: 聯絡電話 + - `postalCode`: 郵遞區號 + - `city`: 城市 + - `district`: 區域 + - `street`: 街道地址 + - `details`: 詳細資訊 (樓層、門牌等) +- **範例**: + ``` + Address { + recipientName: "張小明", + phone: "0912-345-678", + postalCode: "100", + city: "台北市", + district: "中正區", + street: "重慶南路一段 122 號", + details: "3 樓" + } + ``` +- **注意事項**: + - Address 是 immutable,任何修改都會產生新的 Address 實例 + - 驗證邏輯包含郵遞區號和城市的一致性檢查 + +--- + +## 跨 Context 術語對照 + +某些術語在不同 Context 中有不同含義,需要特別注意: + +| Order Context | Inventory Context | 說明 | +|---------------|-------------------|------| +| Order | Reservation Request | Order 觸發庫存預留請求 | +| Order Line | Reserved Item | 每個 Order Line 對應一筆庫存預留 | +| Confirmed | Committed | Order 確認對應庫存的正式扣減 | + +| Order Context | Warehouse Context | 說明 | +|---------------|-------------------|------| +| Order | Fulfillment Order | 訂單轉為履行指令 | +| Shipped | Out for Delivery | 狀態名稱不同但意義相近 | + +| Order Context | Payment Context | 說明 | +|---------------|-------------------|------| +| Order Total | Payment Amount | 金額概念相同,但 Payment 還包含手續費 | +| Order Confirmed | Payment Captured | 確認時機相同,視角不同 | + +--- + +## 版本歷史 + +- **v2.3 (2025-10-20)**: 新增 Fulfillment Status,澄清與 Order Status 的差異 +- **v2.2 (2025-09-15)**: 修正 Order Modification Window 規則,從 15 分鐘調整為 30 分鐘 +- **v2.1 (2025-08-01)**: 新增跨 Context 術語對照表 +- **v2.0 (2025-06-01)**: 重大改版,引入 Domain Events 章節 +- **v1.0 (2025-01-01)**: 初版發布 +``` + +--- + +## 產出物使用指南 + +### 何時產出這些文件？ + +1. **Bounded Context Analysis**: + - 當識別出新的 Context 時 + - 當 Context 職責有重大變化時 + - 作為新團隊成員的 onboarding 材料 + +2. **Context Map**: + - 系統架構設計階段 + - 規劃跨團隊協作時 + - 重構或服務拆分時 + - 定期 review (建議每季更新) + +3. **Ubiquitous Language**: + - 項目啟動時建立初版 + - 持續更新,任何術語變更都要記錄 + - 用於解決團隊溝通誤解時 + +### 文件維護原則 + +- **Single Source of Truth**: 每個 Context 的分析文件由該 Context 的負責團隊維護 +- **Version Control**: 所有文件應納入版本控制,重大變更要有 changelog +- **Living Documentation**: 這些不是一次性產出,要隨著系統演化持續更新 +- **Accessibility**: 確保所有相關人員都能輕易存取這些文件 + +### 輸出格式建議 + +- **Markdown**: 適合納入版本控制,易於協作編輯 +- **Confluence/Notion**: 適合需要豐富排版和快速分享 +- **Mermaid/PlantUML**: Context Map 的圖形化表達 +- **ADR (Architecture Decision Records)**: 記錄重要的設計決策和權衡 diff --git a/skills/ddd-strategic-design/references/pm-questions.md b/skills/ddd-strategic-design/references/pm-questions.md new file mode 100644 index 0000000..3d7897c --- /dev/null +++ b/skills/ddd-strategic-design/references/pm-questions.md @@ -0,0 +1,90 @@ +# Product Manager Interview Questions + +產品經理訪談的目標是理解業務目標、優先順序、以及產品策略。這些資訊幫助識別核心域 (Core Domain)、支撐域 (Supporting Subdomain) 和通用域 (Generic Subdomain)。 + +## Phase 1: 業務背景與目標 + +**目的：建立業務脈絡，理解為什麼要做這個系統** + +1. 這個產品 / 系統要解決什麼業務問題？ +2. 主要的商業目標是什麼？（營收、效率、用戶體驗？） +3. 誰是主要的利益相關者？（客戶、內部團隊、合作夥伴？） +4. 這個系統在公司的整體業務中扮演什麼角色？ +5. 如果這個系統失敗，對業務的影響是什麼？ + +**追問技巧：** +- "為什麼這個目標很重要？" - 挖掘深層業務價值 +- "有沒有具體的數字目標？" - 理解成功指標 +- "有哪些競爭對手在做類似的事情？" - 了解市場定位 + +## Phase 2: 功能優先順序與範圍 + +**目的：識別核心域，區分必要功能與次要功能** + +1. 如果只能保留三個功能，你會選擇哪三個？為什麼？ +2. 哪些功能是產品的競爭優勢？ +3. 哪些功能是「必須有」(Must-have)，哪些是「最好有」(Nice-to-have)？ +4. 未來 6-12 個月的產品規劃重點是什麼？ +5. 有哪些功能是你們刻意不做的？為什麼？ + +**追問技巧：** +- "這個功能對哪類用戶最重要？" - 識別不同用戶群體 +- "如果沒有這個功能會怎樣？" - 測試真實重要性 +- "這個功能的投資報酬率如何評估？" - 理解價值衡量 + +## Phase 3: 流程與決策點 + +**目的：理解端到端流程，發現關鍵決策點和業務規則** + +1. 能否描述一個典型的用戶旅程？從開始到結束？ +2. 在這個流程中，有哪些關鍵的決策點？ +3. 什麼情況下流程會失敗或需要特殊處理？ +4. 哪些步驟是自動化的？哪些需要人工介入？ +5. 不同部門或團隊在這個流程中如何協作？ + +**追問技巧：** +- "這個決策是根據什麼規則做的？" - 挖掘業務規則 +- "有沒有例外情況？" - 發現邊界案例 +- "這個流程通常需要多長時間？" - 理解時間約束 + +## Phase 4: 約束與限制 + +**目的：識別系統邊界、外部依賴和技術 / 業務約束** + +1. 有哪些法規或合規要求必須遵守？ +2. 系統需要與哪些外部系統整合？ +3. 預算和資源的限制是什麼？ +4. 時程上有什麼硬性期限嗎？ +5. 技術上有哪些限制或偏好？ + +**追問技巧：** +- "這個限制是可以協商的嗎？" - 區分硬性和軟性約束 +- "如果突破這個限制會帶來什麼風險？" - 理解約束的嚴重性 +- "有沒有替代方案？" - 探索彈性空間 + +## Phase 5: 成功指標與驗收標準 + +**目的：建立清晰的成功定義，幫助後續驗證設計決策** + +1. 你如何衡量這個產品是否成功？ +2. 有哪些關鍵指標 (KPI) 需要追蹤？ +3. 上線後多久會檢視成果？ +4. 什麼情況下你會認為需要重大調整？ +5. 用戶的成功長什麼樣子？ + +**追問技巧：** +- "這個指標的目標值是多少？" - 量化期望 +- "如何收集這些數據？" - 理解測量機制 +- "有沒有領先指標可以提早預測？" - 找出早期信號 + +## 訪談後整理重點 + +根據 PM 訪談，應該能識別： + +1. **核心域** (Core Domain) - 產品的競爭優勢，業務最關心的部分 +2. **支撐域** (Supporting Subdomain) - 必要但不是差異化的功能 +3. **通用域** (Generic Subdomain) - 可以用現成解決方案的部分 +4. **Bounded Context 候選** - 根據業務能力和功能群組識別的邊界 +5. **關鍵業務規則** - 影響設計決策的重要約束 + +記住：PM 提供的是業務視角，需要與領域專家和終端用戶的訪談交叉驗證。 diff --git a/skills/ddd-strategic-design/references/user-questions.md b/skills/ddd-strategic-design/references/user-questions.md new file mode 100644 index 0000000..20f7f45 --- /dev/null +++ b/skills/ddd-strategic-design/references/user-questions.md @@ -0,0 +1,169 @@ +# End User Interview Questions + +終端使用者訪談的目標是理解真實的使用情境、工作流程、痛點和期望。使用者的實際操作往往揭示了系統真正需要支援的用例，而非理論上的設計。 + +## Phase 1: 背景與脈絡 + +**目的：了解使用者的角色、經驗和使用情境** + +1. 能否簡單介紹一下你的工作內容？ +2. 你每天會花多少時間使用這個系統？ +3. 你使用這個系統多久了？ +4. 除了這個系統，你還會用哪些工具來完成工作？ +5. 你是單獨使用，還是需要與團隊協作？ + +**追問技巧：** +- "你覺得這個系統在你的工作中重要嗎？" - 理解系統定位 +- "如果沒有這個系統，你會怎麼做？" - 了解替代方案 +- "有沒有人教過你怎麼用？還是自己摸索的？" - 理解學習曲線 + +## Phase 2: 典型工作流程 + +**目的：觀察真實的操作序列，發現用例和任務模式** + +1. 能否示範一下你平常是怎麼使用這個系統的？ +2. 請描述一個你今天實際完成的任務，從頭到尾是怎麼做的？ +3. 這個任務通常需要多長時間？ +4. 完成這個任務需要經過哪些步驟？ +5. 有沒有一些步驟是你覺得可以跳過或簡化的？ + +**追問技巧：** +- "為什麼要這樣操作？" - 理解操作背後的意圖 +- "有沒有其他方法可以達到同樣的目的？" - 發現替代流程 +- "如果這一步出錯，你會怎麼辦？" - 理解錯誤處理 + +## Phase 3: 痛點與困難 + +**目的：識別使用者體驗的瓶頸和挫折點，這些往往指向設計改善的機會** + +1. 在使用過程中，什麼地方最讓你感到困擾？ +2. 有沒有經常出錯或需要重做的步驟？ +3. 什麼情況下你會覺得「系統怎麼這麼笨」？ +4. 你最希望改善的功能是什麼？ +5. 有沒有一些「變通方法」(workaround) 你不得不使用？ + +**追問技巧：** +- "這個問題多久會遇到一次？" - 評估頻率 +- "這個問題會耽誤你多少時間？" - 量化影響 +- "你有向誰反映過這個問題嗎？" - 理解溝通管道 + +## Phase 4: 決策點與判斷 + +**目的：理解使用者如何做決策，什麼資訊影響他們的選擇** + +1. 在 [某個步驟] 你如何決定要選擇哪個選項？ +2. 你需要哪些資訊來做這個決定？ +3. 有時候會選錯嗎？什麼情況下會選錯？ +4. 做這個決定時，你會考慮哪些因素？ +5. 如果不確定該怎麼選，你會怎麼辦？ + +**追問技巧：** +- "系統有沒有給你足夠的資訊來做決策？" - 評估資訊充分性 +- "你希望系統能提供什麼建議或提示？" - 發現輔助需求 +- "有沒有某些選項你從來不會選？為什麼？" - 理解選項的實用性 + +## Phase 5: 異常與例外情況 + +**目的：發現「不在手冊上」但實際會遇到的情況** + +1. 有沒有遇過系統無法處理的情況？ +2. 遇到特殊情況時，你是如何處理的？ +3. 什麼情況下你會需要尋求他人協助？ +4. 系統有沒有給過你意外或奇怪的反應？ +5. 有沒有一些「理論上不該這樣做但實際上得這樣做」的操作？ + +**追問技巧：** +- "這種情況常見嗎？" - 評估特殊情況的頻率 +- "你覺得系統應該怎麼處理這種情況？" - 收集改善建議 +- "這種情況對你的工作影響大嗎？" - 評估優先順序 + +## Phase 6: 協作與溝通 + +**目的：理解多人協作的模式和資訊交換的需求** + +1. 你的工作成果會交給誰？ +2. 你需要從其他人那裡得到什麼資訊？ +3. 團隊成員之間如何協調工作？ +4. 有沒有需要同時編輯或共同決策的情況？ +5. 如果有衝突或不一致，如何解決？ + +**追問技巧：** +- "你們如何知道對方的進度？" - 理解可見性需求 +- "有沒有遇過「我以為你會做,你以為我會做」的情況？" - 發現協作盲點 +- "系統如何幫助或阻礙你們的協作？" - 評估協作支援 + +## Phase 7: 期望與理想狀態 + +**目的：理解使用者的願景，這有助於識別真正的需求而非表面要求** + +1. 如果可以改變這個系統的一件事，你會改變什麼？ +2. 你理想中的工作流程是什麼樣子？ +3. 有沒有其他系統或工具有你希望這個系統也有的功能？ +4. 如果系統能自動幫你做一件事，你希望是什麼？ +5. 你認為新手使用這個系統最大的障礙是什麼？ + +**追問技巧：** +- "為什麼這個功能對你很重要？" - 理解深層需求 +- "如果有了這個功能，你的工作會有什麼改變？" - 評估價值 +- "這個改變會不會影響到其他人？" - 考慮連鎖效應 + +## Phase 8: 頻率與模式 + +**目的：量化不同用例的重要性，幫助優先順序決策** + +1. 你最常做的任務是什麼？多久做一次？ +2. 哪些功能你每天都會用？ +3. 哪些功能很少用，但用的時候很關鍵？ +4. 在一天當中，什麼時候最常使用這個系統？ +5. 使用的強度會隨著時間變化嗎？（月初月底、旺季淡季？） + +**追問技巧：** +- "能給我一個大概的百分比嗎？" - 量化使用分布 +- "這個任務緊急嗎？還是可以慢慢做？" - 理解時效性 +- "如果這個功能變慢了，對你的影響大嗎？" - 評估效能敏感度 + +## Phase 9: 學習與適應 + +**目的：理解使用者如何學習和適應系統，這影響 UI 設計和訓練需求** + +1. 當初學習使用這個系統時，什麼最難理解？ +2. 現在還有什麼功能你不太會用嗎？ +3. 你有沒有發現一些「早知道」的使用技巧？ +4. 如果要教新人，你會從哪裡開始教？ +5. 系統的哪些部分是「憑直覺」就知道怎麼用的？ + +**追問技巧：** +- "你是怎麼學會這個的？" - 理解學習路徑 +- "系統的提示或說明有幫助嗎？" - 評估輔助功能 +- "有沒有一些術語或概念讓你困惑很久？" - 發現溝通障礙 + +## Phase 10: 觀察而非只是詢問 + +**重要提醒：真實的使用行為往往與使用者的描述不同** + +在訪談過程中，儘可能： +- **請使用者實際操作** - "能否示範給我看？" 而不只是 "你會怎麼做？" +- **觀察猶豫和錯誤** - 使用者卡住或選錯的地方往往最有價值 +- **注意非語言訊號** - 皺眉、嘆氣、快速點擊都是痛點的訊號 +- **記錄實際用詞** - 使用者如何稱呼功能和概念 +- **關注繞過的功能** - 使用者刻意不用的功能可能有問題 + +## 訪談後整理重點 + +根據終端使用者訪談，應該能識別： + +1. **使用者旅程地圖** - 完整的任務流程和接觸點 +2. **高頻用例** - 最常執行的任務和操作序列 +3. **關鍵痛點** - 影響體驗的主要問題 +4. **實際術語** - 使用者真正使用的詞彙 (vs. 系統或專家用的術語) +5. **協作模式** - 多人協作的方式和需求 +6. **隱藏需求** - 使用者的變通方法揭示的真實需求 + +記住：使用者訪談提供的是「系統被如何使用」的真相，而非「系統應該如何使用」的理論。這些洞察需要與 PM 的業務目標和領域專家的規則結合，才能設計出既符合業務又好用的系統。 + +## 跨角色驗證 + +將三種訪談結果交叉比對： +- **PM 說的重要功能，使用者真的常用嗎？** - 驗證業務假設 +- **使用者的痛點，在領域專家眼中是規則問題還是 UI 問題？** - 區分根因 +- **領域專家的術語，使用者真的這樣說嗎？** - 調整 Ubiquitous Language