Challenges of Event Modeling

https://eventmodeling.org/resources/

ช่วงนี้เป็นช่วงที่พวกเรา 3 พี่น้อง กำลังเตรียมตัวที่จะเปิดคลาส Event Modeling ให้กับคนใน ODT เผื่อจะมีประโยชน์กับเพื่อนๆที่อยู่แต่ละ site และโปรเจกต์ในอนาคตของทีมพวกเราเองด้วย ตัวผมเองเลยอยากจะจดบันทึกการบ้านที่ผมได้ไปหามาจากแหล่งต่างๆ ซึ่งอาจจะเป็นประโยชน์กับตัวผมในอนาคตที่จะต้องเปิดคลาสนี้กับพี่ๆในทีมอีก 2 คน

Event Modeling คือ รูปแบบการสื่อสารวิธีนึง ที่ช่วยให้เห็นภาพการทำงานของระบบ เป็น timeline

มาทำความรู้จัก Event Modeling เพิ่มเติมได้ที่บทความด้านล่างนี้เลยครับ

Event Modeling

เริ่มกันเลยครับ โจทย์ที่ได้รับมอบหมายของ Week ที่ผ่านมา คือ

1. Event, Commands, Read/View Model คืออะไรนะ?
2. What and Why The 7 Steps of Event Modeling?

โดยใน 2 ข้อนี้อยากให้ความสำคัญกับ *ถ้าจะอธิบายให้เข้าใจง่ายๆ หรือเมื่อพูดขึ้นมาคนที่ได้ยินสามารถเห็นภาพและเข้าใจ จะต้องเล่ายังไง?

เอๆ แล้ว 2 คำถามนี้เกิดขึ้นได้อย่างไรล่ะ?

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

ครับงั้นผมขอเริ่มส่งการบ้านจากข้อมูลและแหล่งอ้างอิงที่ผมหามาของตัวผมเองก่อนเลย

4 Building Blocks

Bobby Calderwood Presentation

1. Event

คือสิ่งที่เกิดขึ้นจริง ภายในธุรกิจของเรา และเปลี่ยนสถานะของระบบ ถูกร้อยเรียงตามลําดับเวลาที่เกิดขึ้น

ยกตัวอย่าง

• จาก ลูกค้าเพิ่มสินค้าลงในตะกร้าสินค้า นำมาเขียนเป็น Event จะได้ สินค้าถูกเพิ่มลงในตะกร้าสินค้าของลูกค้าแล้ว (เขียนเป็น Past Tense หรือการเล่าเรื่องในอดีตที่เกิดขึ้นไปแล้วและจบไปแล้วในอดีต)
• จาก ลูกค้าชําระเงิน นำมาเขียนเป็น Event จะได้ การชําระเงินของลูกค้าเสร็จสมบูรณ์

คุณสมบัติของ Event

• ใช้สีส้มแสดง (ในบางรูปแบบการนำเสนอ)
• อธิบายกระบวนการทางธุรกิจ Events ทั้งหมดรวมกันสามารถอธิบายกระบวนการทางธุรกิจได้อย่างครอบคลุม
• บริบทที่เกี่ยวข้อง Events สามารถจัดกลุ่มตาม “บริบทที่เกี่ยวข้อง” (Bounded Context) เพื่อแยกส่วนของระบบที่แตกต่างกัน

สรุปง่ายๆ อีเวนต์ช่วยให้คุณมองเห็นภาพการทํางานของระบบธุรกิจของคุณตามลําดับเวลา เหมือนกับการเล่าเรื่องราวการดําเนินธุรกิจทีละขั้นตอน

Bobby Calderwood Presentation

2. Commands

คือการแสดง ความตั้งใจ ของผู้ใช้ที่จะ เปลี่ยนแปลงสถานะ ของระบบ คิดง่ายๆ ว่า คำสั่ง เปรียบเหมือนการ สั่งงาน ให้ระบบทำอะไรสักอย่าง

ตัวอย่าง

• ผู้ใช้กดปุ่ม เพิ่มสินค้าลงในตะกร้า (This is the user’s intent)
• ระบบได้รับคำสั่ง เพิ่มสินค้าลงในตะกร้า (This is the Command)

คุณสมบัติของคำสั่ง

• ใช้สีฟ้าแสดง (ในบางรูปแบบการนำเสนอ)
• เขียนเป็น ประโยคบอกเล่า (Imperative Tense) เน้นการสั่งงาน เช่น เพิ่ม, ลบ, ปรับปรุง
• เป็นจุดเริ่มต้น ของการเปลี่ยนแปลงสถานะระบบ
• ส่งผลให้เกิดอีเวนต์ (Event) ขึ้นหลังจากระบบประมวลผลคำสั่งเสร็จสิ้น

สรุปง่ายๆ คำสั่ง คือ ตัวแทนของผู้ใช้ในการบอกระบบว่าต้องการเปลี่ยนแปลงอะไร

เพิ่มเติม ระบบประมวลผลคำสั่งอาจสำเร็จหรือล้มเหลว ขึ้นอยู่กับเงื่อนไขต่างๆ

Bobby Calderwood Presentation

3. Read/View Model

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

ตัวอย่าง

• หน้าจอแสดงสินค้าในตะกร้าของผู้ใช้
• หน้าจอแสดงสถานะการสั่งซื้อ

คุณสมบัติของ Read Model

• ใช้สีเขียวแสดง (ในบางรูปแบบการนำเสนอ)
• สร้างขึ้นจากอีเวนต์ (Event) อีเวนต์ต่างๆ ที่เกิดขึ้นภายในระบบ จะถูกนำมาประมวลผลเพื่อสร้าง Read Model ที่ตรงกับความต้องการ
• แสดงผลใน Wireframes Wireframes คือ ภาพโครงร่างเบื้องต้นที่ใช้ในการออกแบบหน้าจอของระบบ
• มีหลายรูปแบบ ขึ้นอยู่กับรูปแบบการเข้าถึงข้อมูลที่แตกต่างกัน

สรุปง่ายๆ Read Model คือ ข้อมูลที่ถูกดึงมาจากอีเวนต์ต่างๆ เพื่อแสดงผลให้ผู้ใช้ทราบ

เพิ่มเติม ระบบอาจมี Read Model หลายแบบเพื่อรองรับการแสดงผลข้อมูลที่แตกต่างกัน

Bobby Calderwood Presentation

4. Wireframes

คือ ภาพโครงร่างเบื้องต้น ของ หน้าจอผู้ใช้ (User Interface) หรือ ประสบการณ์การใช้งานของผู้ใช้ (User Experience)

หน้าที่หลัก

• ช่วยให้ Designer(UX/UI) และ Developer มองเห็นภาพรวมของหน้าจอต่างๆ ในระบบ
• ใช้ในการออกแบบฟังก์ชันการทำงานเบื้องต้น
• ช่วยให้ทุกฝ่าย (Designer, Developer, Business Owner) เห็นตรงกันก่อนลงมือพัฒนาจริง

ลักษณะของ Wireframes

• อาจเป็นภาพกราฟิก แสดงโครงสร้างพื้นฐานของหน้าจอ ประกอบด้วย ปุ่ม, ช่องข้อความ, รูปภาพ
• อาจไม่ใช่ภาพกราฟิก เช่น คำอธิบายการทำงานของ API หรือ กระบวนการทำงานอัตโนมัติ
• จัดกลุ่มตาม Swimlanes (เลนว่ายน้ำ) เพื่อแยกบทบาท/บุคคลที่เกี่ยวข้อง เช่น หน้าจอสำหรับ Admin, หน้าจอสำหรับ Customer

ตัวอย่าง

• Wireframes ของหน้าจอเข้าสู่ระบบ
• Wireframes ของหน้าจอแสดงรายการสินค้า

ข้อดี

• ช่วยประหยัดเวลาและทรัพยากรในการพัฒนา
• ช่วยให้แก้ไข ปรับเปลี่ยนฟังก์ชันการทำงานได้ง่ายในช่วงออกแบบ
• ช่วยให้สื่อสารแนวคิดการออกแบบระหว่างทีมงานได้ชัดเจน

สรุป Wireframes คือ เครื่องมือเบื้องต้นที่ช่วยในการออกแบบระบบ ช่วยให้มองเห็นภาพรวม ฟังก์ชันการทำงาน และ บทบาทของผู้ใช้

The 7 Steps Of Event Modeling

Event Modeling ทำได้ง่ายๆ เพียง 7 ขั้นตอน เพื่อให้ได้ผลลัพธ์ที่เป็น “แบบพิมพ์เขียว” (blueprint) ของระบบ

1. ระดมสมอง (Brainstorming)

ขั้นตอนแรกของการสร้าง Event Model คือการระดมสมอง

https://eventmodeling.org/posts/what-is-event-modeling/Step-1_large.jpg

ขั้นตอน

1. อธิบายเป้าหมายโครงการ ผู้นำกลุ่มจะอธิบายเป้าหมาย ข้อมูลเบื้องต้นของโครงการ
2. จินตนาการระบบ ผู้เข้าร่วมจะจินตนาการว่าระบบจะมีลักษณะ หน้าตา และการทำงานอย่างไร
3. ลิสต์เหตุการณ์ ผู้เข้าร่วมจะลิสต์เหตุการณ์ทั้งหมด ที่คิดว่าอาจเกิดขึ้นภายในระบบ

ข้อควรจำ เฉพาะเหตุการณ์ที่เปลี่ยนสถานะ (State-changing events) เราจะโฟกัสที่เหตุการณ์ที่ ส่งผลต่อการเปลี่ยนแปลงข้อมูลภายในระบบเท่านั้น

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

สรุป ขั้นตอน Brain Storming ช่วยให้ทุกคนมีส่วนร่วม โดยโฟกัสที่การลิสต์เหตุการณ์ที่ส่งผลต่อการเปลี่ยนแปลงข้อมูลภายในระบบ

2. เรียงร้อยเหตุการณ์: สร้างเส้นเรื่อง (The Plot)

หลังจากระดมสมอง เหตุการณ์ต่างๆ กันไปแล้ว ขั้นตอนต่อไปคือ การเรียงร้อยเหตุการณ์ เหล่านั้น ให้กลายเป็น เส้นเรื่อง (The Plot) ที่สมเหตุสมผล

https://eventmodeling.org/posts/what-is-event-modeling/Step-2_large.jpg

ขั้นตอน

1. จัดเรียงเหตุการณ์ตามลำดับ นำเหตุการณ์ที่ลิสต์ไว้ จัดเรียงตามลำดับที่มันจะเกิดขึ้นจริงภายในระบบ
2. ทบทวนไทม์ไลน์ ทุกคนในทีมร่วมกันตรวจสอบไทม์ไลน์ที่จัดเรียง เพื่อยืนยันว่า เหตุการณ์เหล่านี้ เกิดขึ้นอย่างต่อเนื่องกัน และมีความสมเหตุสมผล

ตัวอย่าง

• ผู้ใช้เข้าสู่ระบบ (Login)
• ผู้ใช้เลือกสินค้าลงตะกร้า (Add item to cart)
• ผู้ใช้ชำระเงิน (Checkout)
• ระบบแจ้งสถานะการสั่งซื้อสำเร็จ (Order confirmation)

สรุป การเรียงร้อยเหตุการณ์ ช่วยให้มองเห็นภาพรวมของกระบวนการทำงานภายในระบบ และตรวจสอบความสมเหตุสมผลของลำดับเหตุการณ์ที่เกิดขึ้น

3. สตอรี่บอร์ด (The Story Board)

ขั้นตอนนี้ มุ่งเน้นการนำเสนอภาพ เพื่อให้ผู้เรียน เรียนรู้ในรูปแบบของภาพ (Visual Learners) ซึ่งจะช่วยให้เข้าใจกระบวนการทำงานของระบบได้ง่ายขึ้น

https://eventmodeling.org/posts/what-is-event-modeling/Step-3_large.jpg

3.1 หน้าจอผู้ใช้ (UX Concurrency)

• นำ ภาพร่างเบื้องต้น (Wireframes) หรือ หน้าจอตัวอย่าง วางไว้ด้านบนของ แบบพิมพ์เขียว (Blueprint)
• แบ่ง Swimlanes เพื่อแสดงหน้าจอของผู้ใช้แต่ละประเภท (กรณีที่มีผู้ใช้หลายประเภท)

ข้อจำกัด ห้ามวางหน้าจอซ้อนทับกัน เนื่องจากเราต้องการแสดงการเปลี่ยนแปลงสถานะของระบบ ในแต่ละช่วงเวลา (Vertical Slice)

สรุป สตอรี่บอร์ด (Story Board) ช่วยให้ทุกคนมองเห็นภาพ ซึ่งจะช่วยให้เข้าใจกระบวนการทำงานของระบบ และการเปลี่ยนแปลงสถานะในแต่ละช่วงเวลา

4. ระบุการป้อนข้อมูลของผู้ใช้ (Identify Inputs)

ขั้นตอนนี้ มุ่งเน้นการระบุ ว่า ผู้ใช้ป้อนข้อมูลอะไร เพื่อเปลี่ยนแปลงสถานะของระบบ ในขั้นตอนก่อนหน้านี้ เราได้สร้างสตอรี่บอร์ด (Story Board) ซึ่งแสดงหน้าจอผู้ใช้ (Wireframes) โดยในขั้นตอนนี้ เราจะโฟกัสที่การระบุ คำสั่ง (Command) ที่ผู้ใช้ ใช้ในการเปลี่ยนแปลงข้อมูลภายในระบบ

https://eventmodeling.org/posts/what-is-event-modeling/Step-4_large.jpg

ขั้นตอน

1. เชื่อมโยงเหตุการณ์กับหน้าจอ สำหรับเหตุการณ์ที่เกิดขึ้นจากการกระทำของผู้ใช้ เราจะเชื่อมโยงเหตุการณ์นั้นกับหน้าจอที่เกี่ยวข้อง
2. ระบุคำสั่ง (Command)

• ในแต่ละหน้าจอเราจะเพิ่ม กล่องสีน้ำเงิน เพื่อแสดง คำสั่ง ที่ผู้ใช้ ใช้ในการป้อนข้อมูล
• คำสั่งเหล่านี้อาจจะเป็น ข้อมูลที่ผู้ใช้กรอกลงในช่องข้อความ ปุ่มที่ผู้ใช้กดหรือ สถานะของระบบที่เกิดขึ้นอยู่เบื้องหลัง (Client State)

ตัวอย่าง

• แสดง “หน้าจอรายละเอียดสินค้า”
• ผู้ใช้กดปุ่ม “เพิ่มสินค้าลงตะกร้า”
• Command “เพิ่มสินค้าลงในตะกร้า” (แสดงในกล่องสีน้ำเงิน)
• เกิด Event “สินค้าถูกเพิ่มลงในตะกร้าสินค้าของลูกค้าแล้ว”

สรุป ขั้นตอนนี้ ช่วยให้เราเข้าใจว่า ผู้ใช้ป้อนข้อมูลอะไร ผ่านทางหน้าจอ และส่งผลต่อการเปลี่ยนแปลงข้อมูลภายในระบบ อย่างไร

5. ระบุผลลัพธ์ที่ผู้ใช้เห็น (Identify Outputs)

ขั้นตอนนี้เราจะโฟกัสที่ ข้อมูลที่ระบบแสดง ให้ผู้ใช้เห็น เชื่อมโยงกับข้อมูลที่เราสะสมไว้จากเหตุการณ์ต่างๆ (Events)

https://eventmodeling.org/posts/what-is-event-modeling/Step-5_large.jpg

ขั้นตอน

1. เชื่อมโยงเหตุการณ์กับหน้าจอ สำหรับเหตุการณ์ที่ส่งผลต่อการเปลี่ยนแปลงข้อมูลภายในระบบ เราจะเชื่อมโยงเหตุการณ์นั้นกับหน้าจอที่เกี่ยวข้อง
2. ระบุผลลัพธ์ (View) ในแต่ละหน้าจอ เราจะเพิ่ม สัญลักษณ์ (Icon) เพื่อแสดง ผลลัพธ์ (View) ที่ระบบจะแสดงให้ผู้ใช้เห็น ผลลัพธ์เหล่านี้ มักจะเชื่อมโยงกับเหตุการณ์หลายๆ เหตุการณ์

ตัวอย่างผลลัพธ์

• ปฏิทินแสดงห้องว่างในระบบจองโรงแรม
• ยอดเงินรวมในตะกร้าสินค้า

สรุป ขั้นตอนนี้ ช่วยให้เราออกแบบระบบ โดยคำนึงถึงข้อมูลที่จำเป็นสำหรับผู้ใช้แต่ละประเภทในแต่ละสถานการณ์

6. ประยุกต์ใช้กฎของ Conway (Apply Conway’s Law)

หลักการนี้ระบุว่า โครงสร้างขององค์กร (ทีมพัฒนา) จะส่งผลต่อการออกแบบของระบบ (ซอฟต์แวร์) ที่องค์กรนั้นสร้าง โดยในขั้นตอนนี้ เราจะประยุกต์ใช้ กฎของ Conway โดยการจัดกลุ่มเหตุการณ์ (Events)

https://eventmodeling.org/posts/what-is-event-modeling/Step-6_large.jpg

วัตถุประสงค์

• แบ่งระบบออกเป็นส่วนย่อย (Subsystems)
• เพื่อให้ทีมพัฒนาที่แยกจากกัน สามารถรับผิดชอบระบบย่อยเหล่านั้นได้
• ส่งเสริมให้แต่ละทีมมีความเชี่ยวชาญเฉพาะด้าน
• ป้องกันปัญหาที่เกิดจากการสื่อสารระหว่างทีม

ขั้นตอน

จัดกลุ่มเหตุการณ์ตาม Subsystems พิจารณาว่า เหตุการณ์ไหนมีความเกี่ยวข้องกัน และจัดกลุ่มเหตุการณ์เหล่านั้น โดยแต่ละกลุ่มจะเป็นระบบย่อย ของระบบทั้งหมด

ตัวอย่าง ระบบอีคอมเมิร์ซ

• Subsystem 1: การจัดการสินค้า
• Subsystem 2: การจัดการตะกร้าสินค้า
• Subsystem 3: การชำระเงิน

สรุป การจัดกลุ่มเหตุการณ์ตามระบบย่อย ช่วยให้เราออกแบบระบบที่มีโครงสร้างชัดเจน ส่งเสริมการทำงานร่วมกันแบบเป็นทีม และตรงตามหลักการของการแบ่งงาน (Specialization)

7. การจำลองสถานการณ์ (Elaborate Scenarios)

ขั้นตอนสุดท้ายมุ่งเน้นการ สร้างสถานการณ์จำลอง เพื่ออธิบายการทำงานของระบบ

https://eventmodeling.org/posts/what-is-event-modeling/blueprint_large.jpg

ขั้นตอน

1. เชื่อมโยงแต่ละขั้นตอนกับ Command หรือ View/Read Model ทุกขั้นตอนในเวิร์คโฟลว์จะเชื่อมโยงกับ คำสั่ง (Command) ข้อมูลที่ผู้ใช้ป้อนเข้าสู่ระบบ หรือ ผลลัพธ์ (View/Read Model) ข้อมูลที่ระบบแสดงให้ผู้ใช้เห็น
2. การสร้างสถานการณ์จำลอง (Scenarios) ผู้เข้าร่วมทุกคน ร่วมกันสร้างสถานการณ์จำลอง โดยใช้รูปแบบ “Given-When-Then” หรือ “Given-Then”

ตัวอย่าง

• Given (เงื่อนไขเริ่มต้น): ผู้ใช้เข้าสู่ระบบสำเร็จ
• When (เหตุการณ์ที่เกิดขึ้น): ผู้ใช้เพิ่มสินค้าลงในตะกร้า
• Then (ผลลัพธ์ที่คาดหวัง): ระบบแสดงรายการสินค้าในตะกร้า

3. ทบทวนโดยผู้แทนบทบาทต่างๆ สถานการณ์จำลองเหล่านี้ จะได้รับการตรวจสอบโดยผู้แทนบทบาทต่างๆ ภายในระบบ (ตัวอย่าง: ผู้ดูแลระบบ, เจ้าของผลิตภัณฑ์)

สรุปแล้ว จาก 7 ขั้นตอนนี้ จะช่วยให้คุณมองเห็นภาพรวมของระบบ ผ่านมุมมองของเหตุการณ์ที่เกิดขึ้นจริง

ก็จบไปแล้วกับข้อมูลที่ผมเตรียมมาสำหรับการบ้านของ Week นี้ ส่วนใน Week ถัดไปนั้นเนื้อหาก็น่าจะค่อนข้างเข้มข้นขึ้น เพราะตอนนี้พวกเราก็พยายาม Implement ตัว Event Modeling กับสักระบบนึงอยู่ และไม่รู้ว่าจะมีเรื่องอะไรมา Challenge ให้พวกเราได้เรียนรู้กันต่อไปอีกหลังจากนี้

สำหรับวันนี้ก็ขอขอบคุณเพื่อนๆที่เข้ามาอ่านเพื่ออัปเดตความรู้ของตัวเองในวันนี้กันนะครับ ผมหวังว่าบทความนี้จะเป็นประโยชน์ไม่มากก็น้อยสำหรับเพื่อนๆและตัวผมเองที่ต้องการหาข้อมูลเกี่ยวกับ Event Modeling เพิ่มเติมครับ

Link Ref:

Event Modeling: What is it?

Building Information Systems using Event Modeling — Confluent

Interview with Event Modeling Founder — Adam Dymitruk

Event Modeling