Problem Domain 會是我們真正要專注的 domain。
先建立 Model 🚀
- 這個 Model 其實算是「解決者」要負責的。（需求方只要出一張嘴） → Problem Domain Model（基於問題領域建立的模型，真實世界的「抽象」）
- 若之前都是資料庫導向，畫物件（ERModel）模型就會卡住。
- 模型不是越真越好，夠用（可以解決問題）就好。
領域專家：以為自己知道領域知識的人。
設計：
- 決定 Form （決定形式）與 Context （脈絡）的邊界。
- 挑選要放什麼，不要放什麼。
- 早上的繞境建城 140 年，就不會放在課程分享中。
Force：應力，是中性的。
- Force 形塑 Form。
- 問題的限制條件（Force）把 Form（解決方案）給「捏」出來。
- ⭐ 越厲害的工程師，越容易找得到 Force 。 → Non-function requirement 。
- 沒有 Force 就沒有問題。（沒有限制條件，那麼怎樣做都可以）
- 要分辨好 Force 的強弱
一個 class 通常就一個人動工
- 模組化做得不好，分工也會做得不好。（所以要做好 Open-Close，將「不關這個 class 職責的給分開」）
- 從類別圖看不出到底是哪種 Design Pattern。
DDD 可視為 OOAD 的進階版本
- 適合當代分散式與反應式（事件驅動）的系統開發。
Kanban 系統的三大業務邏輯：
- Visualize：視覺化
- WIP
Work in Progress：Push / Pull 工作流程，通常會限制「最大可工作數量」。- Push：推工作給工作者；生產好賣給消費者。
- Pull：工作者自己「拿」工作；接單生產。
- Manage Flow
- 其他 domain 相關
- Cycle Time：週期時間
- Lead Time：前置時間 / 交期
🪪 Domain Event
- XXX edited：CRUD event，並非 Domain Event
- Task based event：一項一項任務區分的事件。
- event 切小，就知道 User 「確切具體」做了什麼。
最終一致性的問題
Domain
- Generic (sub) domain：通用子領域。（常有套裝服務可以直接買、直接用）
- Core domain：核心領域（具有商業競爭力的領域）。 ← 這個是最重要的，花時間把 core domain 找出來。
- Supporting (sub) domain：支持領域（像是支撐輔助的領域）。
Core domain：需要整個 core 才具有完整業務邏輯的，就是一整個「核心領域」。（看板需要 Board + Workflow + Swimlane + … 才有）
Event Storming
- 🟩 Read model：提供「使用者」是否做 command 決策的資訊。（e.g. 菜單、點餐按鈕）
- 🟪 Policy（選用）：事件做完之後，接續要做的 Follow Up。（e.g. 飲料購買完之後，要可以抽獎。而這是只有某些時候才有這種活動，是業務考量） ← 這是業務邏輯！
- *備註：原本的 DDD 根本沒有提到 Event Storming 這種方法，而是後人才把這兩種方法給串連起來一起使用。
軟體的規格（需求），通常都蠻抽象的。
Specification by Example
- 法條就是 spec，判例就是 example
- 用舉例的方式，來「驗證」規格。
- ⭐ Key Example：找到關鍵案例，表達某一個 spec。