Event-carried state transfer
บทความนี้มีเนื้อหาต่อจาก
เมื่อเกิด command ที่ทำให้ internal state มีการเปลี่ยนแปลง Event-carried state transfer(ECST) จะ publish event ที่หน้าตาของ schema เปรียบเสมือนเงาสะท้อนที่บอกว่า มีอะไรเปลี่ยนแปลงไปบ้าง ซึ่งจะแตกต่างจาก Event notifications เมื่อข้อมูลมีเปลี่ยนแปลง consumers จะได้รับ message ที่สามารถอ้างอิงถึงข้อมูล เช่น id, timesamp หากต้องการข้อมูลเพิ่มเติมจะต้อง request ไปที่ producer สิ่งนี้ทำให้ระบบยึดติดกันเกินไป
รูปแบบของ ECST เมื่อ consumers ได้รับ message จะทำการบันทึกเฉพาะฟิลด์ที่เกี่ยวข้องกับ domain ของตัวเอง ไม่ใช่การ copy message หรือ entity ทั้งก้อนมาเก็บไว้ วิธีการนี้ทำให้ระบบไม่ depend on upstream data(แหล่งที่มาของข้อมูล) หมายความว่า ถ้า producer ใช้งานไม่ได้ ระบบในฝั่ง consumer ก็ยังสามารถทำงานได้ ด้วยข้อมูลที่มีอยู่แล้ว
ปกติ message ของ ECST สามารถแบ่งได้ 2 ประเภท คือ snapshot และ actually modified วิธีการเลือกใช้งานให้สังเกตที่ command และ event เป็นหลัก
For Example:
Warehouse Activities
สมมุติว่าเรามีระบบ warehouse เมื่อมีสินค้าเข้าผ่านระบบ receiving (กระบวนการรับสินค้า) พนักงานจะตรวจสินค้า กรอกข้อมูลเข้าในระบบและกดปุ่มบันทึก ตรงนี้เกิด command ชื่อว่า ReceiveOrder (ตามรูปด้านบน) เมื่อบันทึกข้อมูลสำเร็จ ระบบก็ publish event ชื่อ OrderReceived ไปที่ mesaage broker
ในฝั่งของ consumers หลังได้รับ event จะแกะ message และเอาเฉพาะ field ที่เกี่ยวข้องกับ domain ของตัวเอง บันทึกลงฐานข้อมูล
ตัวอย่าง Message ของ OrderReceived เป็นประเภท Snapshot
{
"ReceivedDateandTime": "2023-01-22T00:00:00",
"OrderNumber": "N00001",
"Vendor": "Flours and Mixes",
"ReceivedBy": "Adam Smith",
"Description": "55 Lbs",
"Quantity": 35,
"Unit": "bag",
"Price": 75
}
เวลาผ่านไป… สินค้าใกล้หมด
พนักงานสั่งสินค้า สินค้ามาส่ง พนักงานกรอกจำนวนสินค้าเข้าระบบและกดปุ่มบันทึก ตรงนี้เกิด command ชื่อว่า ReplenishOrderQuantity ระบบบันทึกข้อมูลสำเร็จพร้อมกับ publish event ที่ชื่อว่า OrderQuantityReplenished ไปที่ mesaage broker
ตัวอย่าง Message ของ OrderQuantityReplenished เป็นแบบ Actually Modified
{
"OrderNumber": "N00001",
"Quantity": 100,
"Unit": "bag"
}
ความท้าทายในการใช้ ECST
- Data Accurately สิ่งที่เราเห็นได้ชัดเจนคือ ข้อมูลจะกระจัดกระจายตาม consumers นั่นหมายความว่าข้อมูลในแต่ละ components อาจจะไม่ตรงกันและอาจเกิดข้อผิดพลาดในการนำข้อมูลไปใช้ทำ something
- Event Schema เนื่องจาก upstream data เป็นผู้กำหนด schema ถ้ามีการเปลี่ยนแปลงควรคำนึงถึงโอกาสที่ระบบ consumers จะพังเพราะ message หน้าตาไม่เหมือนเดิม
- Security การกระจายข้อมูลไปตาม consumers เราควรจัดการเรื่อง sensitive data และสิทธิ์ในการเข้าถึงข้อมูล เพราะบาง component ไม่มีสิทธิ์ในเข้าข้อมูลบางอย่าง