今天來跟大家聊聊，該怎麼把 Event Storming 的成果進一步轉換為軟體設計吧！
這一個階段就不需要領域專家的協助，可以把相關負責的開發者聚起來一起討論！
本篇概要：
經過昨天的努力，我們可以看到牆上最多的就是 Command 與 Event。而這些並不是單純的商業語言而已，他們都有可能成為你程式中一個個的 Model。比起從瑣碎的規格書中拼湊出 Model 設計，從確切的流程中找出來會更貼近需求！
Aggregate (聚合)的意思就是軟體中的 Model，只是他的顆粒度可大可小，一個 Aggregate 可以包含數個 Model。所以接下來這個階段，請大家拿出長方形、黃色的 Aggregate 貼在讓你覺得「這個 Aggregate Model 可以處理這個 Command 並發出這個 Event」的 Command 與 Event 之間。簡單來說，就是如果你覺得某個 Command 與 Event 針對同一個 Model 做操作，那就可以貼上去。
通常來說，會飆上 Aggregate 的都是你核心的 Model 元件，這對之後的程式碼設計很有幫助。
其實你可以把 Aggregate 想成是一個 State Machine (有限狀態機)，一個 Model 會有很多的狀態，因此一種 Aggregate 可能會對應到多組 Command 與 Event。
當你做完第一階段時你會發現，很多 Aggregate 本身不太合理，比如一個 OrderItem (訂單品項)有可能在一開始成為一個 Aggregate，但實務上，你每次修改 OrderItem 時，一定會跟他本身的 Order 做互動以及邏輯檢查，比如一個 Order 的 OrderItem 數量不能為 0 ，這種規則我們稱為 Invariant (不可變規則)。
因此，這時你可以把 OrderItem 都替換成 Order。這邊可以發現 Aggregate 可以做到在他的邊界裡的 Model 都能符合一致的商業邏輯規定。
有時候，Aggregate 的命名沒有那麼容易，他有可能很抽象，或是你找不到適合的名字。也有可能你不知道他該不該再跟更大的概念聚合。
可以思考：
有了 Aggregate 後，你可以拿出你的奇異筆將你覺得功能類似的地方圈起來，這個界線就有可能成為你的 Bounded Context。關於 Bounded Context 的敘述可以看前面的文章。
找出 Bounded Context 間的關鍵 Event ，那有可能成為你的 Domain Event 或 Intergation Event
How to use Event Storming to introduce Domain Driven Design
iThome鐵人賽
看影片追技術