SDD‐Domain Model - daniel-qa/Vue GitHub Wiki
Domain Model 關心業務語意與規則
不綁定 API、資料來源或傳輸格式
不反映資料結構，只表達概念與狀態
為什麼「不綁定格式」這件事超重要？
因為你其實是在做三件長線正確的事 👇
1️⃣ Domain 會變最慢
API 改版 3 次，domain 通常 0 次 👉 綁格式 = 每次 API 改都要動核心邏輯
2️⃣ Domain 是 AI / 測試 / 規則的最佳輸入
你之後如果：
用 AI 產測試
用 Agent 操作流程
寫規則引擎
AI 最需要的是：
乾淨、穩定、有語意的模型
不是雜訊滿滿的 DTO。
「業務語言模型」最標準、最被接受的說法是：
Domain Model
在 AI / DDD / 軟體工程裡，幾乎都是用這個詞。
- Data Model 的分類
「如果明天 UI 全砍，用 API / CLI 操作，這個欄位還有意義嗎？」
有 => Data Model
沒有 => UI Model
- 建議做法
先提供這三個資料 → AI / Windsurf 可生成基礎骨架
再補充 domain rules / events / policies → 完整落實 DDD
三個核心 + NOTE = DDD 所需的上下文、規則、流程說明
AI 或 Windsurf 就能生成大部分符合規範的程式碼與流程，減少人工解釋。
- Windsurf DDD 上下文說明
在使用 AI 或生成程式碼時，需提供以下三個維度的上下文給 Windsurf：
| 名稱 | 用法 |
|---|---|
| Data Model | 直接表示資料結構（Schema） |
| Data Domain | 表示聚合根、Bounded Context |
| Workflow | 表示業務流程 |
說明：
- Data Model: 描述每個 Entity 的欄位、型別、關聯等。
- Data Domain: 說明系統的聚合根與邊界，幫助 AI 理解 domain 的邏輯。
- Workflow: 描述業務流程、狀態流轉以及事件觸發規則。
GitHub spec-kit: 這是目前推動 SDD 最核心的開源工具包。
Tessl / Kiro: 這些是新興的平台，旨在實現「人類寫規格，AI 維護程式碼」的願景。
- SDD Level
Spec-first: 先寫好規格，用於當下的開發任務
Spec-anchored: 任務完成後規格保留下來，持續用於功能的演進和維護
Spec-as-source: 規格成為主要的原始檔，人類只編輯規格、不碰程式碼
目前的工具大多只停在第 1 層
Spec-Driven Development (SDD)
DDD：認知層（Cognitive Layer）
對齊人與人
對齊業務與技術
對齊語言與模型
🛠️ SDD：執行層（Execution Layer）
對齊 spec 與 code
對齊設計與實作
對齊意圖與結果
一個負責「想對」，一個負責「做對」。
4️⃣ 放在一起才是完全體（這才是重點） 正確的組合方式是： DDD → 產生 Domain Knowledge ↓ 轉成結構化 Spec ↓ SDD → 驅動 AI / 人類實作