Introducing Event Storming

ช่วงนี้หัวหน้าให้ผมดูแลน้องๆ สรุปบทความจาก MSDN Magazine ผมมองเป็นของดีที่น่าจะไม่ค่อยมีคนอ่านมากนักนะครับ จากที่ช่วยหัวข้อของน้องไป ไปสะดุดกับ Blog ที่มีการอ้างอิงจากบทความครับ เรื่อง "Introducing Event Storming" เลยนำมาสรุปไว้นะครับ

What is Event Storming

Event Storming เป็นกิจกรรมที่ให้เราช่วยสำรวจสิ่งที่เราสนใจ หรือขอบเขต(Domain) ของธุรกิจที่ซับซ้อนออกมาครับ เน้นคำว่า "Visualize everything" ทำให้เห็นภาพ และ "Outside-in"

Event Storming is good

• Powerful - นำคนที่เกี่ยวข้องมาร่วมกันสร้าง Business Flow ให้เห็นภายรวม ภายในเวลาอันสั้น
• Engaging - ตรงเป้าหมาย เพราะ Idea ต่างๆ นำไปสู่การพูดคุย และมีการแชร์คำตอบกัน เพื่อสร้าง Model ออกมา
• Efficient - มีประสิทธิภาพ ผลลัพธ์ที่ได้ เข้ากับการพัฒนาแบบ Domain Driven Design (เหมาะกับ Event Sourcing Approach) และหา Context และ Aggregate Boundaries ได้รวดเร็ว
• Easy - รูปแบบมันง่าย ไม่ซับซ้อน ทำให้คนที่ไม่เข้าใจเรื่อง Technical ไม่ต้องกังวล และแสดง Idea ออกมาได้เต็มที่
• Fun

How does it work

📌 Invite the right people - ดึงคนที่ใช่

• คนที่ใช่ คือ ใคร ? สำหรับผมมองว่าเป็นคนที่เกี่ยวข้องกับสิ่งที่เราสนใจ โดยผสมกันระหว่าง คนที่มี Idea หรือ คำถาม / คนที่อยากรู้คำตอบ และคนที่คาดว่ารู้คำตอบ
• ขนาดการประชุม 6-8 คน
• อาจจะต้องมีการทำ Ice-Breaking ละลายพฤติกรรม หานำคนหลายฝ่าย เข้ามาคุยกัน
• !!! ขั้นตอนนี้สำคัญมากนะครับ ถ้าเลือกคนผิด ผลลัพธ์ที่ได้จะแย่

📌 Provide unlimited modelling space - มีพื้นที่ใช้ออกแตก Idea อย่างไม่จำกัด

• บ่อยครั้งบางปัญหาที่ซับซ้อน ถูกละเลยไป เพราะ ผู้ประชุมคิดว่า ปัญหามันจบแล้ว สรุปการประชุมกันเต็มลงบนกระดาษ A4 หรือ Whiteboard แล้ว
• มีการแนะนำให้ใช้กำแพง + paper roll มีอะไรเติม Idea ได้ต่อ อย่าไปเขียนบนกำแพงนะ ฮ่าๆ
• ไม่ควรมีโต๊ะ หรือ เก้าอี้ในการประชุม เพราะ มันทำให้เกิดการจับเก็บกลุ่ม เช่น คน Active - ไม่ Actve หรือ เด็กหน้าห้อง-หลังห้อง เป็นต้น

📌 Explore the domain starting from Domain Event

• Domain Event คือ อะไรหละ ? - ตัว Domain Event อะไรบางอย่าง อาจจะเป็นเหตุการณ์ที่มีความสำคัญกับตัว Domain ได้แสดงพฤติกรรม (Behavior) หรือมองง่ายๆ มีการ Call Method ไปแล้ว
• โดยวิธีการนี้จะเป็นการดึงความต้องการ ออกมาจากคนที่เป็น Non Technical

• Domain Event เกิดอะไรได้บ้าง ลองดูตามรูปเลยครับ
  • จาก User มี Action
  • จากระบบภายนอก
  • เกิดจากระยะเวลาที่ผ่านไป
  • ตัว Event ที่เกิดอาจจะเป็นลูกโซ่ มีความเกี่ยวเนื่องกันได้
• สำหรับการจัดการใช้ Post-it สีส้ม มาแปะ โดยให้เรียงตามช่วงเวลา (Timeline)

📌 Explore the origin of Domain Events - หาที่มาของ Domain Events กัน

• บาง Event เกิดจาก Action ของตัว User มองว่าเป็น Command -> โดยแทนด้วย Post-it สีน้ำเงิน
• ถ้ามันเกิดจากระบบอื่นหละ หรือมีการเปลี่ยนไปตามเวลา(External systems or of the time passing) โดยแทนด้วย Post-it สีม่วง
• บางครั้ง Event แรกเป็นผลลัพธ์ให้ Event ถัดไป ให้วาง Post-it ของทั้ง 2 Event ไว้ใกล้กัน

📌 Look for Aggregates

• Aggregates คือ อะไร ? - การประมวลผล ตัดสินใจต่างๆ ว่าทำหรือไม่ตาม Logic ที่ทำให้เกิด Domain Events
• ปัญหาเดิม คือ ไอ้ตัว Aggregates เราเห็นภาพ ต่อเมื่อลงมือทำ Coding ไปแล้ว ทำไม ไม่คุยให้เรียบร้อยไปเลยจาก Idea (Post-it) ต่างๆ ที่ถูกจัดเรียงไปแล้วหละ (Outside in Approach)

จากเมื่อกี้สรุปรูปแบบได้ ดังนี้

ฺBONUS จาก Event Storming

• Exploring Subdomains

ในการประชุม ถ้าเรามีผู้เชี่ยวชาญ (Expert) ทำให้เราพบว่าบางเรื่องมีความสัมพันธ์กัน และมีความเกี่ยวข้องกัน หรือป่าว จะว่าไปมันดูคล้ายๆกับการ Clustering(แบ่งกลุ่ม) + Association(หาความสัมพันธ์)

• Exploring Bounded Contexts

พอมีการประชุม เราจะพบมุมมอง หรือ ความสัมพันธ์ที่ซ่อนอยู่ และะหาวิธีการในการจัดการ

• Sketching User Personas

อันที่แล้ว เราได้ Command โดยจากการพูดคุย เราอาจจะได้ข้อมูลดีๆ อย่าทิ้งมันไปใส่รายละเอียดเพิ่ม โดยใช้ Post-it สีเหลือง มาอธิบายเพิ่มเติม

• Sketching Key Acceptance Tests
  - ในการประชุม เราอาจจะเจอรูปแบบ Scenarios ที่สับสน เราควรทำให้มันชัดเจน และทำตัว Acceptance Test เลย
  - ไม่จำเป็นต้องทำ Document หมด เอาที่พอดี
  - แตถ้าผู้ประชุมเป็นพวก tie breaker เราควรเก็บ สกัดความรู้เหล่านั้นออกมา

• Sketching Key Read Model Artefacts

บาง scenarios มันยากที่จะอธิบาย User เข้าใจได้ ก็เขียนลง Post-it ให้เห็นภาพ

คำแนะนำ หรือ เกร็ดอื่นๆ

📌 CHOOSING THE RIGHT FORMAT

• รูปแบบการทำ อาจจะต้องปรับให้เหมาะสมกับวัฒนธรรมขององค์กร หรือ ขนาด และขอบเขตของโครงการ

📌 Minimal Scope

• เราไม่จำเป็นต้องทำ Event Stroming ให้ลงลึกจนถึง Class หรือ Package เพราะบางครั้งคนที่เข้าร่วม อาจไม่ใช่ Dev
• ทำเพื่อให้เข้าใจ Business Flow จากการถาม และจัดเรียงความคิด
• แนวคิด Event Storming สามารถนำไปใช้สอนพนักงานใหม่ ฝึกให้ตั้ง Right Question เพื่อให้เข้าใจงานว่าองค์กร กำลังทำอะไรอยู่ เข้าใจ Flow งาน และสร้าง Idea ใหม่ๆ

📌 TURNING THE MODEL INTO CODE

• ผลจากการทำ Event Storming พวก Aggregates Commands และ Domain Events มันสามารถเชื่อมเป็น Software Artefacts สำหรับคำอธิบายของ Artefacts ลองดูในรูปเลยครับ

• ทำ workshop เพื่อเห็นภาพรวม (big picture) และค่อยๆเจาะลงไป แตกจากอันหลัก โดยผลลัพธ์มันใกล้มากๆกับ สิ่งที่ user ต้องการ (What they[user] need) แต่ไม่ใช่ตัว Data Model
• เราสามารถตรวจสอบ Model ได้จากการ Coding เลย ถ้า Model ที่ clear เราสามารถเขียน Code ได้ในเวลาอันสั้น

*** ที่ Thoughtworks - Technology Radar มีคำแนะนำให้ลองใช้ด้วย

หมายเหตุ: ผมทำการสรุป และทำความเข้าใจจาก บทความ "Introducing Event Storming" และ Slide อื่นๆ ที่ประกอบครับ อ๋อคุณ Alberto Brandolini เค้ามีเขียนหนังสือด้วยนะครับ ที่ leanpub ไปกด Wishlist ได้เลย