จากการแบ่งปันและพูดคุยเรื่องของ Event-Driven Architecture ไปนิดหน่อย 3 วัน
พบว่าแนวคิดนี้มันมีเพื่อน ๆ ตามมาเยอะมาก
ไม่ว่าจะเป็น Command, Event, Event sourcing, Aggregate, Replay, DDD (Domain-Driven Design)
และอื่น ๆ อีกมากมาย มันจะเยอะไปไหนนะ !!
(ก่อนจะใช้งานอะไร ก็ควรรู้และเข้าใจที่ไปที่มาของมันหน่อยสิ)
ก็เลยมาสรุปไว้นิดหน่อย
ทั้งความรู้พื้นฐาน และ รูปแบบของการนำไปใช้งาน
Event-Driven Architecture (EDA)
ไม่ได้เป็นแนวคิดใหม่อะไรเลย ซึ่งจะพูดถึง
- Produce event
- Capture event
- Process event
- Persist event
โดยใน Event-Driven Architecture
นั้นจะแยก object ออกมา 2 ตัวหลักคือ
- Command
- Event
แล้ว object ที่สองชนิดต่างกันอย่างไร ?
Command หรือ คำสั่ง
นั่นคือสิ่งที่ส่งเข้ามายังระบบ เพื่อทำบางสิ่งบางอย่าง
และในบาง command ก็คาดหวัง response หรือ ผลลัพธ์กลับไป
โดยที่ command จะเฉพาะเจาะจงมาก ๆ นั่นคือ
มีการกำหนดเป้าหมายที่จะส่งไป
และ รู้ด้วยว่า command ที่ส่งไปจะทำอะไรบ้าง
และ ได้ผลอะไรกลับมา
และ ผลการทำงานอาจจะมีทั้งสำเร็จและไม่สำเร็จ
ส่วนของ Event หรือ เหตุการณ์
มันคือการเปลี่ยนแปลง state หรือ สถานะต่าง ๆ ของระบบงานนั้น ๆ
แน่นอนว่า event เป็นสิ่งที่เกิดขึ้นแล้ว
มักจะเป็นสิ่งที่เกิดขึ้นจาก command ไม่ทางตรงก็ทางอ้อมก็ได้
โดยที่ event ที่ถูกสร้างขึ้นมานั้น
จะไม่สามารถแก้ไขหรือเปลี่ยนแปลงได้
จะไม่สามารถ undo ได้
ที่สำคัญ event จะไม่รู้ว่าปลายทางคือใคร
เหมือนผมตะโกนออกไปดัง ๆ ใครสนใจก็ได้ยิน !!
ส่วนรูปแบบของ Event-Driven Architecture หลัก ๆ
ประกอบไปด้วย
- Notification pattern
- Event-Carried State Transfer (ECST)
- Event Sourcing (ES)
- CQRS (Command Query Responsibility Segregation)
อธิบายเพิ่มเติมนิดหน่อย
Notification pattern
เป็นรูปแบบที่ถูกนำมาใช้งานมากที่สุด เพราะว่า เรียบง่าย และ เป็นธรรมชาติ
นั่นคือ ระบบการทำงานหลัก หลังจากที่ทำงานเสร็จจาก command ต่าง ๆ แล้ว
จะทำการโยน event ต่าง ๆ ออกมา
(เก็บไว้สักที่เช่น Messaging หรือ Event bus)
จากนั้นถ้ามีส่วนงานใดสนใจ event นี้
ก็ทำการรับค่าไป หรือ ทำการ subscribe (ปักตะไคร้ซะ)
ยังไม่พอนะ
ข้อมูลใน event รูปแบบนี้ มักจะมีแต่ id หรือ reference id ของข้อมูลเท่านั้น
ถ้าต้องการข้อมูลเพิ่มเติม ต้องทำ id นี้ไปดึงข้อมูลจากระบบหลักอีกครั้ง
ส่งผลให้ข้อมูลนั้นเป็นค่าล่าสุดเสมอ
(มีคุณสมบัติ Consistency หรือความถูกต้องแน่นอน)
แต่ข้อเสียคือ แต่ละส่วนการทำงานยังผูกมัดกันอยู่ !!
แสดงดังรูป
ดังนั้นแก้ไขปัญหาใน pattern แรกด้วยวิธี Event-Carried State Transfer (ECST)
นั่นคือในแต่ละ event จะมีข้อมูลและรายละเอียดที่ฝั่ง subscribe ใช้งานครบ
แต่ระวังด้วยว่า
ต้องมีข้อมูลเท่าที่จะใช้งานเท่านั้น อะไรที่ไม่ใช้งานก็ไม่ต้องส่งมา ไม่ต้องเผื่อ !!
ทำให้ไม่ต้องไปดึงข้อมูลอีกรอบ
ข้อดีคือ แต่ละส่วนงานตัดขาดออกจากกัน มีความเป็นอิสระ
ได้เรื่องของ availability มาเพิ่มอีกด้วย
แต่ปัญหาที่ได้รับกลับมาคือ
เรื่องของความถูกต้องของข้อมูลนั่นเอง (Eventully Consistency)
แสดงดังรูป
Reference Websites
- https://en.wikipedia.org/wiki/Event-driven_architecture
- https://medium.com/@kasunranasinghe303/four-event-driven-patterns-4b1cad5ac5e3