---
# System prepended metadata

title: Event Storming & Example Mapping
tags: [基礎知識合集]

---

# Event Storming & Example Mapping
###### tags: `基礎知識合集`  
##### 時間：2022/10/23

## Event Storming
### 成果
![](https://i.imgur.com/K7yZ2za.jpg)

### 設計討論
1. 要不要把"玩家已完成動作"改成"玩家已建設建築/Pass"，比較知道在形容甚麼操作。 => 最後決定要，雖然顆粒度可能跟其他event不一致，但組員都能清楚了解這個event意義。


### 心得記錄
- Event Storming (ES) -> 梳理複雜的流程
Example Mapping (EM) -> 梳理複雜的規則
如果ES的Rule或是Policy很複雜，就適合用EM來列出所有情境。
- Event: 都要用過去式，代表已經完成。
- Policy: **Whenever Event then Command** (讓人知道Event和Event之間如何連接)，要全部打清楚，一個字都不能漏，除非policy本身是專有名詞。
e.g. 如果喊價三次沒有人出價，則結束拍賣。
- Rule: **command要遵守rule才會觸發Event**
- Event後面一定要有policy? 不一定，我們不需要很專注在這些死板的規則，主要是要讓團隊有共識。
- 不需要遵守100%正確性，有疑慮就貼春聯(紅色便條)來日討論，否則就有點瀑布式的mindset。
- 以大富翁組為例，有些Event其實很重要，可能不宜過度縮減，例如買賣、抵押、升級。這些動作如果過度濃縮成一個動作，會讓人感覺不到大富翁的精華。
- event storming 通常不鼓勵用箭頭，通常用左右上下來表示關係就好。
- 和activity diagram(流程圖)的差別：activity, event storming都可以表示流程。activity diagram可以讓邏輯收斂(把甚麼情況該做甚麼都畫出來了)，以規則及細節為重，但把太多分支都列出來了，不一定適合event storming，不適合 brainstorming / collaborative modeling。
Event storming可能比較適合大家討論。因為寫得清楚並不一定代表錯誤會越少，有時候大家快速同步，快速開發，會更有效。

### 參考資料
![](https://i.imgur.com/SesLbRy.jpg)
![](https://i.imgur.com/nwc48gp.jpg)
<img src="https://i.imgur.com/i5ixARv.png" alt="drawing" width="300"/>



https://ithelp.ithome.com.tw/articles/10219177



## Example Mapping
* Given:偏向狀態的敘述。
* When:偏向動作的敘述。
* Then:執行完上述的動作之後的狀態。