30-26 之 DDD 戰略設計 2 - 實作方法之 Event Storm ( 有問題 )

13th鐵人賽

馬克

2021-10-11 23:22:36

1317 瀏覽

分享至

事件風暴 Event Storm

事件風暴 : 理解、訪談需求
- 目的 : 將商業流程視覺化，找出核心價值、風險與機會
- 成員 : 引導帥、領域專家、利害關係人
- 三個階段
  - Big Picture : 看到全貌
    - 便利貼
      - 橘色便利貼 :
        
        domain event 商業流程的所有發生的事情
        
        過去式動式，過去發生的事情 ( 下單會有很多意思，如果用已下單，會發生，就只有一個意思了 )
      - 紅色便利貼 : 代表衝突，包含不清楚、不確定、有爭議的事情
      - 黃色 : 使用者 ( user/actor )
      - 淺紫色 : System
    - Step 1. 混沌探索 ( 因為每個可能想到的事件有的會重複，或是打架，又或是用不同字，來說明同一個事情，因為會將這些放到一群 )
    - Step 2. 執行時間
      - Pivotal Event : 關鍵事件，代表不同業務場景階段之間的轉換 ( 用一個紙交帶， )
      - Swimlanes : 平行的業務流程
    - Step 3. People & System : 將人與系統丟進去圖裡
    - Step 4. Explicit Walkthrough : 以講故事的方法，說明這整個 flow 的流程與事情
  - Process Modeling : 商業流程的建模，為了可以理解整個流程
    - 便利貼
      - 藍色 : command
      - 綠色 : read model : 當使用者看到、感受，然後會觸發更多的事情。 ( UI/UX 設計 )
      - 紫色 : policy : 一定規則與限制
    - 為『 domain event 』加上 user → command
    - 思考 read model，就是當用戶看到或知道什麼後，會改變 command 的決策。
    - 思考 policy : 有沒有什麼限制或規則。
    - 過程中可以使用 user story 來討論。
  - Soft Design : 軟體設計
    - Aggregate : 把概念相同的東西放在一起，並且記好 aggregate 就像是 state machine，它有很多的狀態，而這些狀態對應到 domain event。
    - 找出 Bounded Context : 找出軟體的邊界

範例

使用者可以看到畫面上有不同的產品，產品包含影音課程、文章、直播，並且可以購買與觀看，並且購買完成後，並且會寄信給購買者，還會分潤給老師們。

流程 1. Big Picture : 看到全貌

Step 1. 混沌探索
- Domain event ( 假設你在 domain 完成後，已發生的事情 ) ( 橘色便利貼 )
  - 已購買產品
  - 已瀏覽產品
  - 已學習產品
  - 已收到分潤
  - 已收到購買完成信
Step 2. 重新整理，並且確保時間順序
- 順序與平行為 :
  - 平行 A : 瀏覽 → 購買 → 學習產品
  - 平行 B : → 分潤
  - 平行 C : → 收到完成信
- Pivotal Event : 購買
- 問題 ( 紅色便利貼 )
  - 購買產品有沒有限額 ?
  - 只要有看過就算已學習產品嗎 ?
  - 分潤的公式 ?
Step 3. 加上 user ( 黃色便利貼 ) 與 system ( 淺紫色便利貼 )
- 一般使用者 → 透過 API → 已購買產品
- 一般使用者 → 透過前台畫面 → 已瀏覽產品
- 購買產品使用者 → 透過前台畫面 → 已學習產品
- 老師 → 排程定期付錢 → 已收到分潤
- 購買產品使用者 → 透過 API 與 Mail Service → 已收到購買完成信
Step 4. 講故事

流程 2 : Process Modeling : 商業流程的建模

Step 1. 為 domain event 加上 command ( 藍色便利貼 )
- 一般使用者 → 將選擇商品結帳 ( command ) → 透過 API → 已購買產品
- 一般使用者 → 選擇產品總覽頁面 ( command ) → 透過前台畫面 → 已瀏覽產品
- 購買產品使用者 → 選擇產品進行觀看影片 ( command ) → 透過前台畫面 → 已學習產品
- 老師 → 一般使用者購買該老師產品 → 排程定期付錢 → 已收到分潤
- 購買產品使用者 → 購買產品，並且進行付款 ( command ) → 透過 API 與 Mail Service → 已收到購買完成信
Step 2. 思考有沒有什麼事情 real model，會改變 command 的決定。 ( 綠色便利貼 )
- 商品有沒有折扣
- 商品有沒有合購
- 產品是否全部看過
- 商品有沒有 Coupon
Step 3. 思考 policy 有沒有什麼限制或規則。( 深紫色便利貼 )
- 商品有沒有限額
- 商品沒有規則，每個用戶只能買幾次 ?