Event Storming คืออะไร และทำไมต้องใช้

ลองนึกภาพห้องประชุมที่มีคนนั่งอยู่หกคน ทุกคน “เข้าใจ” ว่าธุรกิจของบริษัททำงานยังไง แต่พอให้แต่ละคนวาดออกมา กลับได้ภาพหกแบบที่ไม่เหมือนกันเลย ฝ่ายโปรดักต์เข้าใจอย่างหนึ่ง ฝ่ายบัญชีเข้าใจอีกอย่าง ส่วนนักพัฒนา (dev) ก็เดาเอาจาก code เก่าที่ตัวเองแก้มาสามปี ความรู้เรื่องธุรกิจไม่ได้หายไปไหน — มันแค่ กระจัดกระจายอยู่ในหัวของคนหลายคน และไม่มีใครเห็นภาพเต็มพร้อมกันสักที

Event Storming คือคำตอบต่อปัญหาที่ปวดหัวมากนี้ มันคือเวิร์กช็อปที่พาทุกคนที่รู้บางส่วนของเรื่องราวมายืนหน้าผนังยาวๆ ผนังเดียว แล้วช่วยกันแปะ Post-it สีส้มทีละใบจนเห็นภาพธุรกิจทั้งเส้นภายในไม่กี่ชั่วโมง บทนี้จะทำความรู้จักว่ามันคืออะไร แก้ปัญหาอะไร และทำไมถึงได้ผลดีอย่างน่าประหลาด

ปัญหา: ความรู้ที่กระจัดกระจายเป็นเกาะๆ

องค์กรส่วนใหญ่ไม่ได้ขาดความรู้เรื่องธุรกิจ — ปัญหาคือความรู้นั้น แตกเป็นเกาะ (silos) อยู่คนละที่ ฝ่ายการตลาดรู้ว่าลูกค้าอยากได้อะไร ฝ่ายปฏิบัติการรู้ว่าหน้างานจริงติดขัดตรงไหน ทีม support รู้ว่าเคสประหลาดๆ เกิดบ่อยแค่ไหน แต่ไม่มีใครเอาความรู้ทั้งหมดมาต่อกันเป็นภาพเดียว

พอความรู้อยู่คนละเกาะ สิ่งที่ตามมาก็เป็นวงจรเดิมๆ:

เอกสารล้าสมัย — spec ที่เขียนไว้เมื่อหกเดือนก่อนไม่ตรงกับของจริงแล้ว แต่ยังถูกส่งต่อให้ทีมใช้เป็น “ความจริง”
dev เดาเอา — เมื่อไม่มีใครตอบได้ชัดๆ นักพัฒนาก็ต้องเดาเจตนาของธุรกิจแล้วเขียน code ตามที่เดา
ระบบผิดเป้า — สุดท้ายได้ซอฟต์แวร์ที่ “รันได้” แต่ไม่ตรงกับสิ่งที่ธุรกิจต้องการจริง ต้องมาแก้กันทีหลังด้วยต้นทุนมหาศาล

รากของปัญหาคือ ช่องว่างของการสื่อสาร ไม่ใช่ช่องว่างของความสามารถ ทุกคนเก่งในเรื่องของตัวเอง แต่ไม่มีเวทีที่ทำให้ทุกคน “เห็นตรงกัน” ได้เร็วพอ ก่อนที่ความเข้าใจผิดจะถูกฝังลงไปใน code

flowchart TD
  P1["ในหัวของ PO"] --> G["ช่องว่างของความเข้าใจ"]
  P2["ในหัวของ Dev"] --> G
  P3["ในหัวของลูกค้าจริง"] --> G
  P4["เอกสารเก่าที่ล้าสมัย"] --> G
  G --> R["ระบบที่สร้างออกมาผิดเป้า"]
  classDef hot fill:#f87171,stroke:#b91c1c,color:#1a1a1f;
  class G,R hot;

Event Storming คืออะไร

Event Storming คือ เวิร์กช็อปสำรวจ domain แบบร่วมมือกันทั้งทีม วิธีเล่นเรียบง่ายจนน่าตกใจ: หาผนังยาวๆ (หรือกระดาษโรลแปะยาวทั้งผนัง) เอา Post-it สีส้มกับปากกามาแจก แล้วให้ทุกคนช่วยกันเขียน “สิ่งที่เกิดขึ้นในธุรกิจ” ลงบน Post-it สีส้มทีละเหตุการณ์ แล้วแปะเรียงจากซ้ายไปขวาตามลำดับเวลา

Post-it สีส้มแต่ละใบเรียกว่า Domain Event — แปลตรงตัวคือ “เหตุการณ์ใน domain” กติกาสำคัญที่สุดของมันคือต้องเป็น “สิ่งที่เกิดขึ้นแล้ว” เขียนเป็นกริยาช่องอดีต เช่น OrderPlaced (ออเดอร์ถูกสั่งแล้ว), PaymentCaptured (ตัดเงินสำเร็จแล้ว), FoodDelivered (อาหารถูกส่งถึงแล้ว) ไม่ใช่ปุ่ม ไม่ใช่หน้าจอ ไม่ใช่ตารางในฐานข้อมูล แต่คือ เหตุการณ์ที่มีความหมายต่อคนทำธุรกิจ

พอเอา Domain Event หลายๆ ใบมาเรียงต่อกันตามเวลา จะได้ เส้นเวลา (Timeline) ของธุรกิจทั้งเส้น อ่านจากซ้ายไปขวาก็เหมือนอ่านเรื่องเล่า: ลูกค้าทำนี่ แล้วเกิดนั่น แล้วต่อด้วยโน่น เส้นเวลานี้แหละคือ “แผนที่” ที่ทุกคนในห้องมองเห็นพร้อมกันเป็นครั้งแรก

flowchart LR
  A["ItemAddedToCart"] --> B["OrderPlaced"]
  B --> C["PaymentCaptured"]
  C --> D["FoodDelivered"]
  classDef evt fill:#e8743b,stroke:#b45309,color:#1a1a1f;
  class A,B,C,D evt;

Post-it สีส้มสี่ใบข้างบนนี้คือแก่นของ Event Storming ทั้งหมด — ที่เหลือ (สีฟ้า สีเหลือง สีม่วง) เป็นรายละเอียดที่จะค่อยๆ เติมเข้าไปในบทถัดๆ ไป แต่ทุกอย่างเริ่มจากสีส้มเสมอ เพราะ event คือ “ความจริง” ที่ทุกฝ่ายเห็นตรงกันได้ง่ายที่สุด

ทำไมต้อง event ไม่ใช่ปุ่มหรือหน้าจอ

ถ้าเริ่มจาก “หน้าจอ” หรือ “ปุ่ม” จะติดกับดักการออกแบบ UI ตั้งแต่ยังไม่เข้าใจธุรกิจ แต่ถ้าเริ่มจาก สิ่งที่เกิดขึ้นแล้ว จะโฟกัสที่ “อะไรเกิดขึ้นในโลกจริงบ้าง” ซึ่งเป็นภาษาที่ทั้งคนธุรกิจและ dev เข้าใจตรงกัน — นี่คือเหตุผลที่ Event Storming เริ่มจาก event เสมอ

ที่มา: ไอเดียของ Alberto Brandolini

Event Storming ถูกคิดค้นโดย Alberto Brandolini ที่ปรึกษาด้าน Domain-Driven Design (DDD) ชาวอิตาลี ราวปี 2013 เรื่องเล่าที่ติดปากคือวันหนึ่งเขาต้องรีบทำเวิร์กช็อป model ธุรกิจแต่เครื่องมือวาดไดอะแกรมบนคอมดันช้าและยุ่งยากเกินไป เขาเลยคว้า Post-it กับผนังมาใช้แทน แล้วพบว่า “มันเร็วกว่าและได้ผลกว่ามาก”

Brandolini รวบรวมเทคนิคนี้ไว้ในหนังสือชื่อ Introducing EventStorming (ตีพิมพ์แบบค่อยๆ เขียนต่อเนื่องบน Leanpub) ซึ่งกลายเป็นคัมภีร์หลักของวิธีนี้ ประโยคที่คนชอบยกมาอ้างของเขาคือแนวคิดว่า Event Storming ถูกออกแบบมาเพื่อ “ดึงความรู้ที่ยังไม่ถูกพูดออกมา” ให้ปรากฏบนผนังอย่างรวดเร็ว ก่อนที่ความเข้าใจผิดจะกลายเป็น code ที่แก้ยาก

จุดที่ทำให้ Event Storming แพร่หลายไปทั่วโลกคือมันไม่ต้องใช้เครื่องมือแพงๆ ไม่ต้องมีความรู้ทฤษฎีมาก่อน แค่มีผนัง Post-it ปากกา และ คนที่รู้เรื่องธุรกิจจริง ก็เริ่มได้ทันที

ทำไมมันถึงได้ผล

Event Storming ดูเหมือนแค่ “เอา Post-it มาแปะเล่น” แต่เบื้องหลังมีเหตุผลสามข้อที่ทำให้มันได้ผลจริงเกินคาด

หนึ่ง — พื้นที่ model ไม่จำกัด (unlimited modeling surface) เครื่องมือวาดไดอะแกรมบนคอมมักบังคับให้เราคิดในกรอบแคบๆ ทีละกล่อง แต่ผนังยาวๆ ให้เราแปะ Post-it ได้เป็นร้อยเป็นพันใบโดยไม่ต้อง “เลื่อนหน้าจอ” ทุกคนเห็นภาพทั้งหมดพร้อมกัน เดินไปชี้ไปคุยกันได้ พื้นที่ที่กว้างไม่จำกัดนี้เองที่ปลดล็อกให้ความรู้ไหลออกมาได้เต็มที่

สอง — สัญกรณ์ (notation) น้อยจนใครก็ร่วมได้ จุดเด่นที่สุดของ Event Storming คือมัน “ไม่ต้องเรียนก่อน” ตอนเริ่มมีแค่กติกาเดียว: Post-it สีส้ม = สิ่งที่เกิดขึ้นแล้ว ผู้บริหารที่ไม่เคยเขียน code กับ dev ที่ไม่เคยคุยกับลูกค้า สามารถยืนแปะ Post-it ข้างกันได้อย่างเท่าเทียม ยิ่งคนเข้าร่วมได้ง่าย ความรู้ที่ถูกดึงออกมาก็ยิ่งครบ

สาม — โฟกัสที่ event ทำให้เจอความจริงและความขัดแย้งเร็ว เมื่อเรียง event ตามเวลา ช่องว่างและความไม่ลงรอยจะ “โผล่ออกมาเอง” เช่น มีคนแปะ PaymentCaptured ไว้ก่อน OrderPlaced แล้วอีกคนทักว่า “เอ๊ะ ตัดเงินก่อนสั่งได้ยังไง?” — บทสนทนาแบบนี้แหละคือทองคำ เพราะมันเผยจุดที่ทีมเข้าใจไม่ตรงกันตั้งแต่ยังไม่ได้เขียน code สักบรรทัด จุดขัดแย้งที่ยังตอบไม่ได้จะแปะ Post-it สีแดง (Hotspot) กำกับไว้ แล้วกลับมาคุยทีหลัง

flowchart LR
  subgraph before["ก่อน Event Storming"]
    direction TB
    H1["ความรู้ในหัว PO"]
    H2["ความรู้ในหัว Dev"]
    H3["ความรู้ในหัวลูกค้า"]
  end
  subgraph after["หลัง Event Storming"]
    direction TB
    W["ผนังเดียวที่ทุกคนเห็นตรงกัน"]
  end
  before --> after
  classDef good fill:#86efac,stroke:#15803d,color:#1a1a1f;
  class W good;

สามระดับของ Event Storming

Event Storming ไม่ได้มีสูตรเดียว แต่แบ่งเป็นสามระดับตาม “ความละเอียด” ที่เราต้องการ ค่อยๆ ซูมเข้าจากภาพกว้างไปหารายละเอียดระดับ code

Big Picture — รอบแรกและกว้างที่สุด เชิญคนจากทุกฝ่ายมาระดม Domain Event ของทั้งสายธุรกิจลงบนไทม์ไลน์เดียว เป้าหมายคือ “เห็นภาพรวม” และค้นพบว่ายังไม่รู้อะไรบ้าง (จะลงลึกในบทที่ 2)
Process Modeling — ระดับกลาง เพิ่ม command, actor, policy และ read model เข้ามา เพื่อให้เห็น “กลไก” ที่ทำให้แต่ละ event เกิดขึ้น (บทที่ 3 และ 4)
Design-Level — เจาะลึกเข้าไปใน bounded context เดียว จนละเอียดพอจะแปลงเป็น code ได้จริง (บทที่ 4)

ตอนนี้แค่จำภาพว่ามันคือ “การซูมเข้า” ทีละขั้นก็พอ จะเดินไล่ทั้งสามระดับด้วยตัวอย่างเดียวกันตลอดคอร์ส

ใครควรอยู่ในห้อง

กฎทองของ Brandolini สรุปได้ประโยคเดียว: เชิญ “คนที่มีคำถาม” มาเจอ “คนที่มีคำตอบ” ในห้องเดียวกัน

คนที่มีคำถาม มักเป็นนักพัฒนา (dev) — คนที่ต้องเอาความเข้าใจไปเขียนเป็น code จึงมีคำถามคาใจเยอะว่า “จริงๆ แล้วมันทำงานยังไง”
คนที่มีคำตอบ คือผู้เชี่ยวชาญธุรกิจ (domain expert) — คนที่ทำงานหน้างานจริงทุกวันและรู้ว่าเคสประหลาดๆ เกิดขึ้นได้อย่างไร

นอกจากสองกลุ่มหลักนี้ ควรมี Product Owner (PO) ที่รู้ทิศทางของโปรดักต์ และคนสาย UX ที่เข้าใจมุมของผู้ใช้ ยิ่งมุมมองหลากหลาย ภาพบนผนังก็ยิ่งครบและจริง

กับดักที่พบบ่อยตั้งแต่ยังไม่เริ่ม

Event Storming จะล้มเหลวทันทีถ้าในห้องมีแต่ นักพัฒนาล้วน เพราะจะกลายเป็นการ “เดารวมหมู่” ไม่ใช่การดึงความรู้จริงออกมา หัวใจของวิธีนี้คือต้องมี domain expert ตัวจริงอยู่ด้วยเสมอ ถ้าเชิญคนที่มีคำตอบมาไม่ได้ ให้เลื่อนเวิร์กช็อปออกไปดีกว่าจัดแบบขาดคนสำคัญ

ตัวอย่างที่จะเดินไปด้วยกันทั้งคอร์ส

ตลอดคอร์สนี้จะใช้ตัวอย่างเดียวกันเพื่อให้เห็นภาพต่อเนื่อง คือ app สั่งอาหารเดลิเวอรี ที่ทุกคนน่าจะเคยใช้ — ตั้งแต่กดเลือกเมนู จ่ายเงิน ร้านรับออเดอร์ ไรเดอร์มารับ ไปจนอาหารถึงมือและเรากดรีวิว

🍔 โจทย์ตั้งต้น — app สั่งอาหารเดลิเวอรี

ลองไล่เรื่องราวเป็น Domain Event เรียงตามเวลาดู (ทั้งหมดเป็นกริยาช่องอดีต — สิ่งที่เกิดขึ้นแล้ว):

ItemAddedToCart → OrderPlaced → PaymentCaptured → OrderAcceptedByRestaurant → FoodPrepared → RiderAssigned → FoodPickedUp → FoodDelivered → OrderRated

อ่านจากซ้ายไปขวาก็เหมือนเล่าเรื่องให้เพื่อนฟัง: ลูกค้าหยิบของใส่ตะกร้า สั่งออเดอร์ จ่ายเงินสำเร็จ ร้านกดรับ ทำอาหารเสร็จ จับคู่ไรเดอร์ ไรเดอร์รับอาหาร ส่งถึงมือ แล้วลูกค้าให้ดาว — นี่คือ เส้นเวลาของทั้งธุรกิจ บนผนังเดียว และจะค่อยๆ เติมสีฟ้า เหลือง ม่วง เขียว เข้าไปในบทถัดๆ ไป

จำเก้าใบสีส้มนี้ไว้ให้ดี เพราะทุกบทหลังจากนี้จะกลับมาที่ผนังเดียวกันนี้เสมอ แล้วเติมรายละเอียดทีละชั้นจนมันพร้อมกลายเป็นสถาปัตยกรรมและ code จริงในบทสุดท้าย และถ้าอยากเก็บรายละเอียดของเส้นทางเฉพาะให้ลึกขึ้น ยังมีเทคนิคพี่น้องอย่าง Domain Storytelling ที่ใช้เสริมกันได้ (จะแตะไว้ในบทว่าด้วยการจัดเวิร์กช็อป)

🔗 อ้างอิงเพิ่มเติมใน DevIQ

เจาะลึกแนวคิดต่อได้ที่คลังอ้างอิง DevIQ:

Event Storming — หน้าอ้างอิงเทคนิคนี้โดยตรง สรุปกติกาและขั้นตอนแบบกระชับ ต่อยอดจากภาพรวมที่บทนี้วางไว้
Domain — “โลกของผู้ใช้” ที่เราลงไปสำรวจในเวิร์กช็อป การเข้าใจ domain คือเป้าหมายปลายทางของการแปะ Post-it สีส้ม
Ubiquitous Language — Event Storming เป็นเครื่องมือชั้นดีในการ “ขุด” ภาษากลางนี้ออกมา เพราะทุกคำบน Post-it ถูกเถียงและตกลงกันสดๆ
Domain Storytelling — เทคนิคพี่น้องที่ให้ผู้เชี่ยวชาญ “เล่าเรื่อง” การทำงานจริง ใช้เสริมกับ Event Storming เพื่อเก็บรายละเอียดเส้นทางเฉพาะ

เช็กความเข้าใจ — บทที่ 1

ข้อ 1 / 3

Domain Event (Post-it สีส้ม) ควรเขียนในรูปแบบใด?

Event Storming คือ​อะไร และ​ทำไม​ต้อง​ใช้

ปัญหา: ความ​รู้​ที่​กระจัดกระจาย​เป็น​เกาะๆ

Event Storming คือ​อะไร

ที่มา: ไอเดีย​ของ Alberto Brandolini

ทำไม​มัน​ถึง​ได้​ผล

สาม​ระดับ​ของ Event Storming

ใคร​ควร​อยู่​ใน​ห้อง

ตัวอย่าง​ที่​จะ​เดิน​ไป​ด้วย​กัน​ทั้ง​คอร์ส