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 Stroming สามารถนำไปใช้สอนพนักงานใหม่ ฝึกให้ตั้ง Right Question เพื่อให้เข้าใจงานว่าองค์กร กำลังทำอะไรอยู่ เข้าใจ Flow งาน และสร้าง Idea ใหม่ๆ
• TURNING THE MODEL INTO CODE
  
  • ผลจากการทำ Event Stroming พวก 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 ได้เลย