🎯 EventStorming คืออะไร
-
EventStorming คือ “เวิร์กช็อป / กิจกรรมร่วมมือ” ที่ช่วยให้ทีม — ไม่ว่าจะเป็นคนสายธุรกิจ (non-tech) หรือสายเทคนิค (developers) — มาร่วมกันสร้าง “ภาพรวมของระบบ/กระบวนการธุรกิจ” จากมุมมองของเหตุการณ์ที่เกิดขึ้นจริง (Domain Events)
-
วิธีนี้ไม่ต้องพึ่ง diagram ที่ซับซ้อนหรือเอกสารทางเทคนิคมาก่อน — ใช้แค่ “กระดาษใหญ่ + sticky note + ปากกา” ก็สามารถแสดง flow ของระบบได้อย่างชัดเจน
-
จุดเด่นคือ “ทุกคน” ในทีม — ไม่ว่าจะ developer, product-owner, business-analyst, stakeholder — สามารถมีส่วนร่วมและเข้าใจระบบจากมุมเดียวกัน
เนื้อหานี้เรียบเรียงมาจาก ddd-crew/eventstorming-glossary-cheat-sheet (github.com)
🧩 แนวคิดหลัก (Core Concepts)
เมื่อเริ่มทำ EventStorming เรามักใช้ post-it หลายสี เพื่อแทน “องค์ประกอบ” ต่าง ๆ ของระบบ โดยสีและความหมายหลัก มีดังนี้ (อ้างอิงจากบทความที่สรุปไว้)
| สิ่งที่แทน | ความหมาย / นิยาม | สีที่ใช้ (Sticky-note) |
|---|---|---|
| Domain Event | เหตุการณ์ที่ “เกิดขึ้นแล้ว” และมีความหมายในทางธุรกิจ เช่น “Order Placed”, “Payment Received”, “Product Added” | ส้ม |
| Hotspot | จุดที่มี “ข้อสงสัย / ความไม่ชัดเจน / ความขัดแย้ง” — ใช้เพื่อจับประเด็นที่ทีมต้องกลับมาคุยหรือตัดสินใจเพิ่มเติม | ชมพู (neon pink) |
| Actor / Agent | บุคคล / หน่วยงาน / บทบาทที่เกี่ยวข้องกับเหตุการณ์ — ใครทำอะไร หรือใครได้รับผลกระทบ | เหลือง (post-it เล็ก) |
| System | ระบบ (IT/System) ที่มีหน้าที่เกี่ยวข้องในโดเมน เช่น ซอฟต์แวร์, บริการภายนอก ฯลฯ | ชมพู (post-it สีชมพู) |
| Value | คุณค่า (เชิงบวก/ลบ) ที่เหตุการณ์หรือกระบวนการในโดเมนนั้นสร้างให้กับธุรกิจหรือผู้ใช้ | เขียว / แดง (post-it ขนาดเล็ก) |
| Pivotal Events | เหตุการณ์ “หลัก/สำคัญ” ที่เป็นจุดเปลี่ยนหรือจุดศูนย์กลางของ flow | — (เป็น Domain Event ที่ถูกเน้น) |
| Aggregates / Bounded Contexts | กลุ่มของเหตุการณ์, entities และ logic ที่อยู่ภายใต้ขอบเขตเดียวกัน — ใช้ในการออกแบบซอฟต์แวร์ระดับลึก | (ใช้เมื่อจำเป็น) |
สังเกตว่าจากต้นฉบับ บทความพยายามลดศัพท์เทคนิคที่ซับซ้อนลง เพื่อให้ทีมที่ไม่ใช่สายเทคนิคสามารถร่วมได้ง่ายขึ้น เช่น หลีกเลี่ยงศัพท์ DDD ที่เฉพาะเจาะจง
🧪 รูปแบบ / ระดับของ EventStorming
บทความแยก EventStorming ออกเป็น 3 ระดับ (ขึ้นอยู่กับเป้าหมาย) — โดยทุกระดับใช้แนวคิดเดียวกัน (events → timeline → post-it…) แต่ “ละเอียด / ลึก” ต่างกันตามวัตถุประสงค์
-
Big Picture EventStorming
-
ใช้เพื่อ “ดูภาพรวมของธุรกิจ/โดเมนทั้งหมด” — เหมาะเมื่อต้องการสำรวจว่าองค์กร/ระบบทำอะไรบ้าง, มี flow งานอย่างไร, มี pain point ที่ชัดเจนไหม ฯลฯ
-
เหมาะสำหรับเวิร์กช็อประหว่างทีมใหญ่ (10–30+ คน) บนกระดาษสีขาวแผ่นใหญ่แผ่นเดียว
-
ผลที่ได้คือ “มุมมองร่วม” (shared understanding) ของโดเมนธุรกิจ — เป็นฐานให้ทีมวางกลยุทธ์, ปรับโครงสร้าง, หาจุดที่ควรปรับปรุง ฯลฯ
-
-
Process-Modelling EventStorming
-
ใช้เมื่อเราโฟกัสที่ “กระบวนการภายในองค์กร” — อยากทำความเข้าใจ flow งาน, หาจุดติดขัด (bottleneck), มองหาการปรับปรุง process หรือเลือกจุดที่ควรแยกระบบออกจากงานที่ manual / สายธุรกิจทั่วไป
-
จะมีองค์ประกอบอื่น ๆ เพิ่มเข้ามา เช่น Commands/Actions, Query Models (ข้อมูลที่ใช้), ระบบ IT, กฎธุรกิจ (Policies), เหมาะกับการเตรียมปรับปรุงระบบก่อนทำซอฟต์แวร์จริง
-
-
Software-Design (หรือ Design Level) EventStorming
-
เหมาะสำหรับทีมพัฒนา — หลังจากเข้าใจ domain/process แล้ว นำมาสร้างแบบโครงสร้างซอฟต์แวร์จริง: กำหนดโมเดลโดเมน, ขอบเขตของบริการ (microservices), API, contract, ฐานข้อมูล ฯลฯ
-
เป็นจุดที่ “post-it + sticky note + timeline” กลายเป็น “system design artefact” ที่สามารถนำไป implement ได้จริง
-
📝 ขั้นตอนทั่วไปของการทำ EventStorming (สำหรับเวิร์กช็อป)
บทความแนะนำวิธีที่ค่อนข้างเป็นขั้นตอน (facilitated workshop) ดังนี้:
-
เตรียมทีม + วัสดุ — กระดาษขนาดใหญ่ หรือ whiteboard / butcher-paper, post-it หลายสี, ปากกาเมจิก, ห้องที่มีพื้นที่เพียงพอ, facilitator ที่ช่วยจัดการ workshop
-
Check-in กับทีม — เริ่มด้วยให้ทุกคน “พูดคุยเบา ๆ” เช่น สวัสดี พูดถึงความคาดหวังจากเวิร์กช็อป เพื่อสร้างบรรยากาศที่เปิดกว้าง (ไม่ใช่เริ่มด้วยงานทันที)
-
Chaotic Exploration — ให้ทุกคน (ทุกบทบาท) เขียน Domain Events ที่คิดว่าเกิดขึ้นได้ — ไม่ต้องกลัวผิด กลัวซ้ำ แค่ capture “ทุกอย่างที่คิดได้” ของระบบในมุมมองตัวเอง — วางแบบไม่เรียงลำดับก่อน
-
Enforce the Timeline — เมื่อทุกคนเขียนเสร็จแล้ว ร่วมกัน “จัดเรียงเหตุการณ์ตามลำดับเวลา” ลบซ้ำ ถกให้ชัดว่าเหตุการณ์ไหนมาเมื่อไร ทำให้ flow มีระเบียบ (timeline)
-
ระบุ Hotspots / จุดที่ยังสงสัย — ถ้ามีข้อขัดแย้ง คำถาม ความไม่ชัดเจน — ให้ติด post-it สีชมพู (Hotspot) เพื่อให้ทีมมาพูดคุย หรือเก็บไว้สำหรับช่วงถัดไป
-
เพิ่มองค์ประกอบอื่นเมื่อจำเป็น — หลังจากได้ timeline + events แล้ว อาจเพิ่ม Actors, Systems, Policies/Rules, Value, External Systems, Aggregate / Context เป็นต้น (ตามเป้าหมายของเวิร์กช็อป)
-
Check-out / สรุปผล — จบเวิร์กช็อปด้วยการให้แต่ละคนสะท้อนความคิด ความรู้สึก หรือข้อเสนอแนะ — อาจเป็นวง (circle) หรือวิธีอื่น — เพื่อให้มั่นใจว่าทุกคนเข้าใจตรงกันและยินดีในผลที่ออกมา
ผู้ทำหน้าที่ facilitator (ผู้ประสาน) มีบทบาทสำคัญ — ต้องคอยดูให้ทุกคนมีส่วนร่วม สังเกตให้กลุ่มไม่เบี่ยงเบน ประเมินว่าเมื่อไรควรหยุดถก และเมื่อไรควรปล่อยให้กลุ่มคิดเอง
✅ ข้อดี & เหตุผลที่ควรใช้ EventStorming
-
เร็วและเห็นภาพรวมเร็ว — จากที่อาจต้องใช้เวลาเป็นสัปดาห์ในการวิเคราะห์ requirement/flow ระบบ กลับถูกย่นให้เห็นภาพรวมภายในไม่กี่ชั่วโมง/วันเดียวด้วย EventStorming
-
ทุกคน (ทั้ง business & tech) เข้าใจร่วมกัน — ไม่จำเป็นว่าทุกคนต้องรู้โค้ดหรือออกแบบระบบ — แค่เข้าใจเหตุการณ์ (events) ที่เกิดขึ้นจริงในธุรกิจ ก็สามารถร่วมออกแบบได้
-
ยืดหยุ่น / ปรับตามบริบท — จะใช้สำหรับสำรวจโมเดลธุรกิจ (ใหม่), วิเคราะห์ process เดิม, รีแฟคเตอร์ระบบ, หรือออกแบบซอฟต์แวร์ใหม่ ก็ได้หมด
-
ลดความคลุมเครือ / misunderstanding — เพราะทุกอย่างแสดงออกมาเป็นภาพ (visual) — เหตุการณ์, actor, system, flow — ซึ่งมองได้ชัดเจนกว่าการอธิบายด้วยคำพูดหรือ spec แบบ text ล้วน ๆ
📈 แล้วถ้าทำเสร็จ — ต่อจากนั้นควรทำอะไร
บทความแนะนำว่า EventStorming เป็นเพียง “จุดเริ่มต้น” ที่ช่วยให้ทีมมีความเข้าใจร่วม และเมื่อได้โมเดลแล้ว — ถ้าจะพัฒนาเป็นซอฟต์แวร์จริง — สามารถใช้ output จาก EventStorming เป็นฐานในการ:
-
สร้าง Domain Models, ERD, UML diagram (class diagrams, data models)
-
กำหนด ขอบเขตของบริการ / โมดูล / microservices ในสถาปัตยกรรม ถ้าระบบซับซ้อนและแยกเป็นหลายบริการ
-
กำหนดระบบการสื่อสารระหว่างบริการ (APIs / contracts), define logic ของ Commands, Events, Policies, และ implement workflow จริง ๆ ได้อย่างเป็นระบบ
-
ใช้เป็นฐานสำหรับการวางแผนพัฒนา (sprint backlog, user stories) — เช่น mapping จาก Domain Events / Commands → เป็น user stories, epic, task ได้อย่างยืดหยุ่น
✨ สรุป
EventStorming คือ “เครื่องมือ / เวิร์กช็อป” ที่ช่วยให้ทีมที่มีพื้นฐานต่างกัน (ธุรกิจ vs เทคนิค) มาทำความเข้าใจระบบเดียวกัน ผ่านมุมมอง “เหตุการณ์ในโดเมน (Domain Events)” โดยใช้เครื่องมือเรียบง่าย (post-it + whiteboard) — เหมาะสำหรับทั้งการออกแบบ business model, วิเคราะห์ process, หรือออกแบบซอฟต์แวร์
ข้อดีคือได้ ภาพรวมที่ชัดเจน, ลดความคลาดเคลื่อนของความเข้าใจ, ทุกคนมีส่วนร่วม และสามารถต่อยอดไปสู่การออกแบบระบบจริงได้
EventStorming Cheat Sheet (One Page สำหรับการใช้เพื่อแชร์กันภายในทีม)
EventStorming Cheat Sheet
เวิร์กช็อปเข้าใจระบบ ผ่าน “เหตุการณ์” แทนที่จะเริ่มจาก “โค้ด” หรือ “เอกสาร”
1️⃣ EventStorming คืออะไร?
-
เป็น วิธีการทำเวิร์กช็อป เพื่อทำความเข้าใจระบบหรือกระบวนการทำงาน
-
ใช้ เหตุการณ์ในธุรกิจ (Domain Events) เป็นตัวตั้ง เช่น
-
Order Created -
Payment Confirmed -
Invoice Sent
-
-
ใช้แค่ กระดาษยาว + Post-it + ปากกาเมจิก ก็เริ่มได้
-
เหมาะมากสำหรับการคุยร่วมกันระหว่าง
-
ทีมธุรกิจ / ผู้ใช้งานจริง
-
ทีมเทคนิค / Dev / Analyst / Product
-
2️⃣ ใช้เมื่อไหร่ดี?
ใช้ EventStorming เมื่อต้องการ…
-
เข้าใจ ภาพรวมของธุรกิจ อย่างรวดเร็ว
-
แปลง ความรู้จากคนเก่ง ๆ ในองค์กร ออกมาเป็นภาพที่จับต้องได้
-
ลดปัญหา
-
“คุยกันไม่รู้เรื่อง”
-
“dev เข้าใจอีกแบบ business เข้าใจอีกแบบ”
-
-
เตรียมข้อมูลก่อน
-
ออกแบบระบบใหม่
-
ปรับปรุง process เดิม
-
แตก microservices / โมดูลต่าง ๆ
-
3️⃣ ของที่ต้องเตรียม
-
กระดาษยาว / กระดาน / ผนังโล่ง ๆ
-
Post-it หลายสี (อย่างน้อย 3–5 สี)
-
ปากกาเมจิกหัวโต เขียนให้อ่านไกล ๆ ได้
-
เทปกาว / Blue-tack สำหรับแปะ
-
คนในเวิร์กช็อป:
-
คนหน้างาน / เจ้าของ process
-
คนตัดสินใจ (ถ้าได้)
-
ทีมเทคนิค / Analyst / Product
-
Facilitator (คอยดำเนินเวิร์กช็อป)
-
4️⃣ สี / การ์ดหลักที่ใช้ (กำหนดเองได้ แต่แนะนำแบบนี้)
ปรับสีตามสะดวก แต่ให้ความหมายชัดเจนเหมือนกันทั้งทีม
-
🟧 Domain Event (ส้ม)
เหตุการณ์ที่ “เกิดขึ้นแล้ว” และสำคัญต่อธุรกิจ-
เขียนเป็นอดีตกาล เช่น
-
คำสั่งซื้อถูกสร้างแล้ว -
ชำระเงินสำเร็จ -
ยืนยันการจองแล้ว
-
-
-
🟨 Actor / ผู้เกี่ยวข้อง (เหลือง)
ใครเป็นคนทำ? ใครได้รับผล?-
ลูกค้า
-
เจ้าหน้าที่
-
ระบบภายนอก
-
-
🩷 System / ระบบ (ชมพู)
ระบบหรือบริการที่เกี่ยวข้องกับเหตุการณ์-
Web App
-
Mobile App
-
ระบบ CRM
-
Gateway / External API
-
-
💚 / ❤️ Value (เขียว / แดง)
คุณค่าหรือผลกระทบ-
เขียว = ผลดี / สร้างคุณค่า
-
แดง = ปัญหา / Pain / ความเสี่ยง
-
-
🩷 (Neon) Hotspot
จุดที่ยัง ไม่ชัดเจน / ถกเถียง / สงสัย-
เช่น “ตรงนี้ใครเป็นคนอนุมัติแน่ ๆ ?”
-
หรือ “จริง ๆ แล้วขั้นตอนนี้จำเป็นไหม?”
-
หมายเหตุ: ถ้าเริ่มต้นครั้งแรก เน้น Domain Event + Hotspot แค่สองแบบก็พอ แล้วค่อยเพิ่ม Actor/System/Value ทีหลัง
5️⃣ รูปแบบ (Levels) ของ EventStorming
5.1 Big Picture EventStorming
ใช้เพื่อ:
-
เห็น ภาพรวมของทั้งธุรกิจ / ทั้งระบบ
-
เหมาะตอน
-
เริ่มโปรเจกต์ใหม่
-
อยาก map ธุรกิจทั้งสาย
-
มีหลายทีม/หลายระบบเกี่ยวพันกัน
-
ลักษณะ:
-
โฟกัส “เล่าเรื่องตั้งแต่ต้นจนจบ”
-
เน้น Domain Events บนเส้นเวลา (Timeline)
-
ยังไม่ต้องลงดีเทลเชิงเทคนิคมาก
5.2 Process-Modelling EventStorming
ใช้เมื่อ:
-
อยากโฟกัสที่ กระบวนการใดกระบวนการหนึ่ง แบบลึกขึ้น
-
เช่น กระบวนการอนุมัติใบเสนอราคา, ขั้นตอน onboarding ลูกค้า, การปิดงาน service
เพิ่มจาก Big Picture:
-
ระบุ คำสั่ง / Action / Command (อะไร trigger event นั้น)
-
ระบุ กฎ / Policy / Business Rule ที่เกี่ยวข้อง
-
เชื่อม Actor + System กับแต่ละ Event
5.3 Design / Software-Modelling EventStorming
ใช้เมื่อ:
-
จะเริ่มออกแบบระบบ / เขียนซอฟต์แวร์จริง
-
อยากรู้ว่า
-
ขอบเขตของโมดูล / microservices อยู่ตรงไหน
-
ข้อมูล/โมเดลหลักคืออะไร
-
Event ไหนคุยกันระหว่างระบบไหน
-
ทำเพิ่ม:
-
จับกลุ่ม Event เป็น Aggregate / Bounded Context
-
คิดต่อเป็น
-
ERD / Class Diagram
-
API / Message Contract
-
Flow ของระบบที่ implement จริง
-
6️⃣ ขั้นตอนเวิร์กช็อปแบบง่าย (นำไปใช้ได้ทันที)
ขั้นที่ 1: Check-in – ตั้งเวทีให้ถูกโทน
-
ให้ทุกคนรู้เป้าหมายของเวิร์กช็อป
-
อาจให้แต่ละคนแนะนำตัว + บอกว่าคาดหวังอะไร
ขั้นที่ 2: Chaotic Exploration – เขียนทุกอย่างที่คิดได้
-
แจก post-it + ปากกาให้ทุกคน
-
ให้เขียน Domain Events ที่คิดว่าเกิดขึ้นในระบบ
-
กติกา:
-
เขียนทีละ event ต่อ 1 แผ่น
-
เขียนด้วยภาษาเดียวกัน (เช่น ภาษาไทยก็ดี)
-
เขียนเป็นอดีตกาล (“สำเร็จแล้ว / เกิดแล้ว”)
-
-
ยัง ไม่ต้องเรียงลำดับ เอาแค่วางกระจาย ๆ ก่อน
ขั้นที่ 3: Enforce the Timeline – เรียงตามเวลา
-
ร่วมกันเอา Event ทั้งหมดมา เรียงตามลำดับเวลา บนกระดาษยาว
-
ลบ/รวมอันที่ซ้ำกัน
-
ถกกันว่า “อะไรเกิดก่อน–หลัง” จนทุกคนโอเค
ขั้นที่ 4: Mark Hotspots – ชี้จุดที่ยังไม่เคลียร์
-
ถ้าตรงไหนเริ่มถกกันหนัก ๆ / ไม่แน่ใจ
-
แปะ Hotspot (สีชมพู) ไว้
-
ไม่จำเป็นต้องเคลียร์ให้จบ ณ ตอนนั้น
-
-
ช่วยให้ไม่ติดหล่มในรายละเอียดจุดเดียว
ขั้นที่ 5: เพิ่มองค์ประกอบอื่น
แล้วแต่เป้าหมายของเรา:
-
เพิ่ม Actor ว่าใครทำ Event นี้
-
เพิ่ม System ว่าเกิดในระบบไหน
-
เพิ่ม Policy / Rule ถ้ามีกฎธุรกิจ
-
เพิ่ม Value (ดี/แย่) เพื่อหา pain point และ quick wins
ขั้นที่ 6: สรุป & Check-out
-
ให้ทุกคนเดินดู board อีกครั้ง
-
สรุปว่า:
-
ตอนแรกคิดว่าระบบทำงานยังไง?
-
ตอนนี้เข้าใจอะไรใหม่บ้าง?
-
เห็นปัญหาอะไร?
-
โอกาสปรับปรุงอยู่ตรงไหน?
-
7️⃣ ข้อดีของ EventStorming (พูดกับผู้บริหารก็ได้)
-
✅ ได้ภาพรวมที่ชัดเจนภายในเวลาไม่นาน
-
✅ ทุกฝ่ายได้ “ภาษากลาง” ร่วมกัน (ผ่าน Events ไม่ใช่ผ่านศัพท์เทคนิค)
-
✅ ดึงความรู้จาก “คนที่ทำงานจริง” ออกมาอยู่บนผนัง
-
✅ ใช้เป็นฐานไปต่อ:
-
ทำ Process Improvement
-
ทำ System Design
-
แตกเป็น User Stories / Backlog
-
8️⃣ หลังจบเวิร์กช็อป ทำอะไรต่อ?
คุณสามารถนำผลบนผนังไปต่อยอดเป็น:
-
แผนภาพ process (BPMN / Flowchart)
-
Data / Domain Model
-
ร่าง System Architecture / Microservices
-
สร้าง User Stories / Epic / Backlog
-
วางแผนปรับปรุง process หรือออกแบบระบบใหม่
