# DDD Event Storming

## 前言

DDD 只是一種設計模式，沒有對錯

## 情境

敦謙國際，在疫情之下因飯店需求高漲大舉擴張，每個飯店都有自己的系統，導致整合上非常困難，加上平台崛起（agoda, booking.com ...）官網價格高於平台價格（明明平台要抽成，卻還可以賣得更便宜）

## 解決辦法

1. 使旗下飯店可以透過官網訂房，實踐智能旅館
2. 透過 Google Map 導流，與上述平台競爭
3. 採用敏捷開發（沒有行政單位包袱、沒有 legacy code、新團隊唯一問題是整合）

## DDD

1. 產品存在的目的，是為了滿足某個需求
產品存在的意義，象徵著某種技術的進步或是某種價值

2. 共通語言 vs 非共通語言
ex: 切版（前端：html/css, 設計：figma排版）導致團隊溝通的不順暢
**各部門都下意識地阻止其他角色參與“規劃”**

- 細部需求到底是什麼？到底要問誰？(ex: PM 的需求、Design 的需求、RD 的需求)
- 複雜度守恆定律 => 複雜度永遠都在，為了不把複雜度提高，所以需要建立共同語言
- 領域知識：為何而做，且知道怎麼做（商業邏輯知不知道全貌）

## Event Storming

1. 建立功能的討論邊界
2. PM 提出流程 其他參與人員提出問題
3. 找出挑戰
4. 標示問題與贊同機會
5. 設計師提出草圖確保所有人員有共識

**結論**

- PM 在提出流程時，可藉由工程、設計參與顧及未考慮到的部分，同步了解功能可行性
- 設計也在整個過程有了初估的草圖確保後續設計的完整度
- 工程也避免了開發時的疑問，可先規避掉大方向的問題
- 團隊有新成員加入時，可更快地進入狀況
- 導入難度思考？團隊能否快速理解？實作可行性是否符合團隊？團隊中需要誰參與這樣的設計模式？

## DDD 對系統層的意義

DDD 更著重在設計模式，而如何開發並不是重點

### 架構下的系統設計

展示層(UI) ==RestfulAPI==> 應用層 ==Entity(ex:RoomId, Member)==> 領域層(Domain.Share)

## 反思：我需要嗎？

設計模式很多，做法很多種，最後還是得以自己的需求去評估，工具是否帶來方便？還是只是使任務更加煩瑣？