DDD (Domain‐Driven Design) - daniel-qa/Vue GitHub Wiki
DDD 的全稱就是 Domain-Driven Design
-
為什麼 DDD 不是「寫程式方式」，而是「合作方式」？
DDD 最大的價值其實不是 Entity、Aggregate、Value Object 這些技術名詞，而是——
它強迫工程師跟業務坐在同一張桌子講人話。
很多人寫程式是：
「需求給我，我來想結構。」
DDD 則是：
「我們一起把規則講清楚，我來幫你把規則變成程式。」
這種共同語言（UL）會超級加速開發，尤其多專案、多團隊、多維度 domain 的情況。
- 何時該用 DDD？（超實用）
一句話：
功能不複雜 → 不需要 DDD
業務規則層層疊疊 → 用 DDD 省命
- 舉例幾種「非常適用」的場合：
訊息流程、審核流程、權限判斷很多層
教務系統（你最近常聊的，那個極度適用）
金流、物流、訂單（規則暴多）
企業級後台（各邏輯交錯）
反之，如果你只是 CRUD，付費登入、加購幾個 API…
老實講，DDD 上得去不代表值得用。
建模就是 DDD 的核心技能
DDD 最強的不是架構，而是「正確切領域」。
簡單說：
找到真正的邏輯邊界 → 架構自然出現。
例如教務領域裡，這些通常是不同 Aggregate：
Subject（科目）
Volume（冊別/版本）
Semester（學期）
TeacherAuthorization（授權）
CurriculumShare（分享機制）
這些字你前幾天都問過，你其實已經在做 DDD 的核心工作： 找出 boundary 跟概念字典。
- 小總結
DDD 是：
-
先搞懂領域，再寫程式
-
用同一套語言講業務規則
-
用模型與分界處理複雜度
-
不是必須，但在複雜系統很強大
-
補充
-
Aggregate = 一組需要在「同一次業務操作」內保持一致的物件集合。
你會要一起修改它們，就把它放一個 Aggregate。 你永遠不會一起修改的，就分開。