Soda Data Quality CQRS Event Sourcing | SiamCafe Blog

Soda Data Quality กับ CQRS Event Sourcing คืออะไร — ทำความเข้าใจพื้นฐานก่อนลงมือ

ก่อนจะพูดถึงการผสมสามอย่างเข้าด้วยกัน ขออธิบายแยกทีละส่วนก่อน เพราะหลายคนที่เข้ามาอ่านบล็อกนี้มาจากสายเทรดและสายไอทีผสมกัน บางคนรู้จัก Soda

แต่ไม่เคยได้ยิน Event Sourcing บางคนทำไมโครเซอร์วิสมาแปดปีแต่ยังไม่เคยตรวจคุณภาพข้อมูลอย่างจริงจัง

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

CQRS ย่อมาจาก Command Query Responsibility Segregation คือการแยกฝั่งเขียนข้อมูลกับฝั่งอ่านข้อมูลออกจากกัน ฝั่งเขียนรับคำสั่งเปลี่ยนแปลงสถานะ ส่วนฝั่งอ่านออกแบบมาเพื่อคิวรีให้เร็วที่สุด ทั้งสองฝั่งใช้ฐานข้อมูลคนละตัวก็ได้ ส่วน Event Sourcing คือการไม่เก็บสถานะปัจจุบันอย่างเดียว แต่เก็บเหตุการณ์ทั้งหมดที่เกิดขึ้นเรียงตามลำดับ แล้วให้สถานะปัจจุบันเป็นผลลัพธ์ของการเล่นเหตุการณ์ย้อนหลังซ้ำ คล้ายกับที่เราดูกราฟแท่งเทียนย้อนหลังเพื่อสรุปว่าราคามาถึงจุดนี้ได้อย่างไร ทุกแท่งคือเหตุการณ์ ไม่ใช่แค่สถานะสุดท้าย

เมื่อประกอบสามอย่างเข้าด้วยกัน เราได้ระบบที่เก็บประวัติเหตุการณ์ครบถ้วน แยกการอ่านและเขียนให้ขยายตัวได้ และมีด่านตรวจคุณภาพคอยกันข้อมูลเน่าเข้าไปปนในเหตุการณ์ ในปี 2026 ที่ข้อมูลโฟลว์เร็วขึ้นและระบบซับซ้อนขึ้น แนวทางนี้ไม่ใช่ของฟุ่มเฟือยอีกต่อไป แต่เป็นพื้นฐานที่ทีมวิศวกรรมข้อมูลควรมี ผมเองใช้หลักการคล้ายกันในการดูแลระบบสัญญาณเทรดของผม ทุกสัญญาณคือเหตุการณ์ที่ต้องเก็บบันทึกไว้ และทุกฟีดราคาที่เข้ามาต้องผ่านการตรวจสอบก่อนเสมอ

ปัญหาใหญ่ที่สุดของ Event Sourcing คือเหตุการณ์ที่เขียนลงไปแล้วไม่ควรแก้ไข เพราะมันคือความจริงทางประวัติศาสตร์ของระบบ

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

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

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

ตัวอย่างปัญหาจริงที่เจอบ่อยมีดังนี้

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

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

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

สถาปัตยกรรมร่วมกัน — วาง Soda ไว้ตรงไหนของระบบ

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

ชั้นที่สามคือฝั่งอ่าน ประกอบด้วยฐานข้อมูลมุมมองที่ถูกปรับแต่งให้คิวรีเร็ว เช่น ฐานข้อมูลเชิงเอกสารสำหรับหน้าจอ หรือคลังข้อมูลสำหรับรายงาน ชั้นที่สี่และสำคัญที่สุดในบทความนี้คือชั้นตรวจคุณภาพที่วิ่งขนานกับทุกชั้น ซึ่ง Soda รับหน้าที่ตรงนี้

ตำแหน่งที่แนะนำให้วางการตรวจมีสามจุดหลัก จุดแรกคือก่อนบันทึกเหตุการณ์ เราเขียนกฎตรวจในตัวรับคำสั่งเอง เช่น ตรวจว่าฟิลด์สำคัญครบ จุดที่สองคือหลังเหตุการณ์ถูกประมวลผลเป็นมุมมองฝั่งอ่าน เราให้ Soda รันเช็กกับฐานข้อมูลมุมมอง เช่น จำนวนแถวในตารางรายวันต้องใกล้เคียงกับจำนวนเหตุการณ์ในคลัง ถ้าต่างกันมากแสดงว่าตัวปรับปรุงสถานะทำงานตกหล่น จุดที่สามคือรายงานระดับธุรกิจ เช่น ยอดขายรวมจากมุมมองต้องเท่ากับผลรวมจากการเล่นเหตุการณ์ซ้ำ

จุดตรวจ	รอบการรัน	ตัวอย่างกฎ	การกระทำเมื่อพัง
ก่อนเขียนเหตุการณ์	ทุกคำสั่ง	ฟิลด์หลักไม่ว่าง ยอดเงินไม่ติดลบ	ปฏิเสธคำสั่ง ตอบผู้ส่งกลับ
ฐานข้อมูลมุมมองฝั่งอ่าน	ทุก 15 นาที	จำนวนแถวไม่หาย ค่าเฉลี่ยปกติ	แจ้งเตือน รีเซ็ตมุมมองจากคลัง
รายงานธุรกิจ	รายวัน	ยอดรวมตรงกับการเล่นซ้ำ	หยุดเผยแพร่รายงาน สืบสวน

มาถึงส่วนลงมือทำจริง เริ่มจากเตรียมสภาพแวดล้อม ผมใช้วิธีรันผ่านคอนเทนเนอร์เพื่อให้ติดตั้งง่ายและไม่เปื้อนเครื่องหลัก สิ่งที่ต้องเตรียมคือโดกเกอร์

พื้นที่ดิสก์ประมาณสิบกิกะไบต์ และการเข้าถึงฐานข้อมูลฝั่งอ่านของคุณจากเครือข่ายที่รัน Soda

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

ขั้นตอนการติดตั้งและตั้งค่า Soda ให้ตรวจฐานข้อมูลมุมมอง

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

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

ตัวอย่างไฟล์กฎที่ผมใช้กับฐานข้อมูลฝั่งอ่านของระบบตัวอย่าง

dataset: ordersreadmodel

checks:

• id: คอลัมน์รหัสคำสั่งต้องไม่ว่าง

column: order_id check: missing_count = 0

• id: ยอดเงินต้องไม่ติดลบ

column: amount check: min = 0

• id: จำนวนคำสั่งต่อวันไม่ต่ำกว่าร้อยละ 80 ของค่าเฉลี่ย 30 วัน

check: rowcount > avg(rowcount) * 0.8 config: filter: createddate >= currentdate - 1

• id: สถานะคำสั่งต้องอยู่ในชุดค่าที่กำหนด

column: status check: values in [pending, paid, shipped, cancelled]

• id: ไม่มีคำสั่งซ้ำรหัส

column: order_id check: duplicate_count = 0

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

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

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

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

เทคนิคขั้นสูงและแนวปฏิบัติที่ดีสำหรับระบบที่ใช้งานจริง

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

แนวปฏิบัติที่ผมใช้จริงมีดังนี้

• แยกกฎเป็นชั้นตามความรุนแรง ชั้นปิดกั้นสำหรับข้อมูลที่ผิดแล้วต้องหยุดระบบ ชั้นเตือนสำหรับเรื่องที่ต้องรู้แต่ไม่ต้องหยุด และชั้นสถิติสำหรับเฝ้าดูแนวโน้ม
• ใช้ค่าเฉลี่ยเคลื่อนที่เป็นเกณฑ์มาตรฐานแทนค่าคงที่ เพราะธุรกิจและปริมาณข้อมูลเปลี่ยนทุกเดือน กฎที่เขียนค่าตายตัวจะล้าสมัยเร็ว
• เฝ้าดูความเบี่ยงเบนของการแจกแจงค่า ไม่ใช่แค่ค่าต่ำสุดสูงสุด เช่น ถ้าราคาเฉลี่ยต่อคำสั่งดีดขึ้นสามเท่าในวันเดียว นั่นคือสัญญาณเตือนแม้ทุกกฎพื้นฐานจะผ่านหมด
• ทำการตรวจแบบเปรียบเทียบระหว่างฝั่งเขียนกับฝั่งอ่านเป็นประจำ นี่คือข้อดีเฉพาะของสถาปัตยกรรมแยกหน้าที่มีคลังเหตุการณ์เป็นแหล่งความจริงเดียว คุณสามารถเล่นเหตุการณ์ซ้ำเพื่อสร้างมุมมองใหม่ทั้งหมดได้ ถ้าระบบฝั่งอ่านพัง การกู้คืนคือการสร้างมุมมองใหม่จากคลัง ไม่ใช่การงมหาข้อมูลจากแบ็กอัปเก่า
• เก็บผลการตรวจทุกรอบไว้เป็นประวัติ แล้วสร้างแดชบอร์ดแนวโน้มคุณภาพข้อมูล ทำให้เห็นการเสื่อมสภาพก่อนจะกลายเป็นเหตุการณ์วิกฤต

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

การเฝ้าดู แก้ปัญหา และตัวอย่างการใช้งานจริงในสายการเงิน

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

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

สำหรับการเฝ้าดูระบบโดยรวม ตัวชี้วัดที่ต้องเก็บมีดังนี้

• ความหน่วงของการบันทึกเหตุการณ์จากการเกิดจริงถึงเข้าคลัง ควรต่ำกว่าหนึ่งวินาทีในงานแบบเรียลไทม์
• ความล่าช้าของมุมมองฝั่งอ่านเทียบกับคลังเหตุการณ์ เรียกว่าเวลาหล่าก ควรเ

คำถามที่พบบ่อย

Soda คืออะไร และทำงานอย่างไรในการตรวจสอบคุณภาพข้อมูล?

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

เหตุใดข้อมูลเน่าจึงเป็นปัญหาร้ายแรงเป็นพิเศษในระบบ Event Sourcing?

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

ควรวางจุดตรวจสอบคุณภาพของ Soda ไว้ตรงไหนในสถาปัตยกรรม CQRS Event Sourcing?

บทความแนะนำให้มองภาพรวมเป็นสี่ชั้นหลัก ได้แก่ ชั้นรับคำสั่ง (ฝั่งเขียนที่แปลงคำสั่งเป็นเหตุการณ์และบันทึกลงคลังเหตุการณ์) ชั้นตัวกระจายเหตุการณ์ที่ปล่อยเหตุการณ์ใหม่ไปให้ส่วนต่าง ๆ ชั้นฝั่งอ่านที่ประกอบด้วยฐานข้อมูลมุมมองปรับแต่งให้คิวรีเร็ว และชั้นตรวจคุณภาพที่วิ่งขนานกับทุกชั้นซึ่ง Soda รับหน้าที่นี้ ตำแหน่งที่แนะนำให้วางการตรวจมีสามจุดหลัก จุดแรกและสำคัญที่สุดคือก่อนบันทึกเหตุการณ์ลงคลัง เพื่อตัดปัญหาตั้งแต่ต้นทาง นอกจากนี้ยังสามารถให้ Soda รันเช็กทุกครั้งก่อนที่เหตุการณ์จะถูกเผยแพร่ออกไป หรือรันเป็นรอบตามชั่วโมงกับฐานข้อมูลฝั่งอ่าน เพื่อจับความผิดปกติที่อาจเกิดขึ้นภายหลัง เช่น รูปแบบข้อมูลเปลี่ยนไปหลังอัปเดตระบบต้นทางโดยไม่มีใครรู้ตัว

มีแนวทางปฏิบัติจริงอะไรบ้างที่ช่วยจับปัญหาคุณภาพข้อมูลได้เร็วที่สุด?

จากประสบการณ์ที่แชร์ในบทความ มีกฎสองข้อที่ให้ผลตอบแทนสูงสุดคือ ห้าม

แนะนำเพิ่มเติม

🎯 เปิดบัญชี XM Forex → สมัคร

📱 แอป iCafeFX → ดาวน์โหลด

📊 สัญญาณฟรี → รับสัญญาณ

📚 คู่มือเทรด → SiamCafeBook

🤝 สมัคร Partner XM → pipaffiliates.com/c?c=72816&l=th&p=6