Try   HackMD

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)

反思:我需要嗎?

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