# Ch 04. 產生活動與步驟

根據 ADDR，**對齊**後的下一步是**定義**，所以這章主要是講產生活動步驟的部分

## 從工作故事產生活動與步驟

### 活動
為了實現目的所做的勞務，整個活動不一定是人做，也有可能是系統做

### 步驟 (貼近事件)
從活動分解出來的工項單位，根據活動的敘述，步驟也不一定是人做，也可能是系統做
步驟應該是可以單人獨力作業做完的，如果需要多人做，則代表他可能需要拆成更細的步驟

書上提供的活動及步驟範例

> 從活動到步驟階段，需要對 API 跟需求有足夠的了解，因此需要領域專家的專業知識來幫助我們釐清需求跟問題，讓我們可以做出符合目標的產品

### 但如果需求不明確

這時候可以透過事件風暴來讓我們對需求對目標取得理解與共識

## 事件風暴
* 幫助團隊對業務有了一致性的認知
* 對一些名詞類的東西有一個共用的**通用語言 (Ubiquitous Language)**
* 可能需要多場事件風暴的會議才能完整理解全部的業務邏輯

:::warning
書上是以一整個活動來做整個事件風暴，但之前經過的狀況都是 PM 開出一張單，最前面有寫出 User Story，然後我們依據 User Story 再進行事件風暴，但 PM 開的 User Story 可能範圍不會那麼大
因此推測書上應該是以整體活動來看，最後再一段一段的抽取出去成為平常開發的不同單子
:::

### 1. 區分領域事件
建立橘色的便利貼，每張橘色的便利貼都是一個事件；事件通常用過去式來敘述，代表事件已經發生了
通常會以 "已" 開頭，ex. "已"送出訂單
這時先請參與成員根據活動來寫下不同的事件，這時候還不需要排序

### 2. 建立事件敘述
排序事件的發生順序，並去除重複的便利貼，這時要確定參與者都明白每張便利貼的意義
如果發現有不同的分支，可以先移到下面，先以完成一條主要的路線為目標

### 3. 回顧事件敘述與劃分事件範圍
這時需要重新順過整個流程並且確定詞彙統一，如果如果有遺漏或多寫也可以在這時修改
對於名詞有疑義也可以在這時候提出，統一完全部的詞彙之後要把全部的事件都改成一樣的詞彙

### 4. 補充領域資訊
加入其他的便利貼，讓整個流程可以順暢的跑完

橘色：已經發生過的一個事件
藍色：命令，代表執行事件的動作
黃色：聚合，流程中的某些事物的集合
紫色：策略，對於特定事件如何回應，通常會寫成 "當{事件}就{命令}"，通常會在前一個事件到下一個命令中間
紅色：熱點，代表對這個地方有問題，須提出來討論
粉紅色：外部系統
白色：需補充說明的 UI 細節
黃綠色：檢視，代表執行這個命令時所需要的資料，可能是送出的資訊也有可能拿來當作判斷依據的資料
黃色或小人：執行者，須加上名稱

:::warning
~~之前跑的時候所定義的聚合跟書上以及其他地方所代表的聚合好像有點意義落差~~
經過重新對焦後，聚合應該是畫 Event Storming 的過程中，我們發現可以將不同的物件給聚集起來的一種物件，需要跟同伴討論當該聚合出現時，裡面會包含哪些物件，並且不會因為事件或命令的不同而導致聚合每次都長得不一樣
:::

### 5. 回顧完整的流程
最後再順一次，確保一切都順利，每個事件也都有正確的觸發

## 事件風暴的好處

1. 將問題建立成模型
2. 透過事件風暴建立對工作流程、業務邏輯的共同理解
3. 建立一致性的詞彙
4. 在開發設計之前，先對需求或動機進行梳理
5. API 進行開發前，才有機會將客戶的思維導入 API 設計中 (可能可以避免做出來的東西，只是自己心中最棒的成果，而不符合實際狀況

###### tags: `Web API 設計原則：API與微服務傳遞價值之道` `Book`