Data Topologies (Data Topology)

ด้วยเรื่องราวเกี่ยวกับ event และการประมวลผล event ทั้งหมดนี้ เราอาจลืมเรื่องด้านข้อมูลของ EDA ไปได้ง่ายๆ database topology เป็นแง่มุมที่มีเอกลักษณ์และน่าสนใจของสไตล์สถาปัตยกรรมนี้ มันมีตัวเลือกมากมาย แต่ละตัวมี trade-off สำคัญที่ส่งผลกระทบใหญ่ต่อสถาปัตยกรรมโดยรวม เพื่ออธิบาย database topology แบบต่างๆ ภายใน EDA เราจะใช้ตัวอย่างแบบง่ายจากที่แสดงใน Figure 15-3 (ดู Figure 15-33 )

เมื่อลูกค้าสั่งซื้อสินค้า event processor Order Placement จะสร้างคำสั่งซื้อ แล้ว trigger event order placed ซึ่งทั้ง event processor Payment และ Inventory จะตอบสนอง เมื่อการชำระเงินสำเร็จแล้ว event processor Order Fulfillment จะช่วยพนักงานเตรียมคำสั่งซื้อ แล้ว trigger event order fulfilled event processor Shipping จะตอบสนองต่อ event order fulfilled ด้วยการจัดส่งคำสั่งซื้อให้ลูกค้า จบกระบวนการและตอบสนองคำขอของลูกค้าโดยสมบูรณ์

Figure 15-33. A simplified example of the example order-entry system using EDA (ตัวอย่างแบบง่ายของระบบรับคำสั่งซื้อโดยใช้ EDA)

ความซับซ้อนอย่างหนึ่งของ EDA คือ event processor Order Placement ต้องรู้ข้อมูลสองอย่าง: มีสินค้าเหลืออยู่ในสต็อกเท่าไร และมีตัวเลือกการจัดส่งอะไรบ้างตามที่อยู่ของลูกค้า วิธีที่มันจะได้ข้อมูลนี้มาขึ้นอยู่กับประเภทของ database topology ที่สถาปัตยกรรมใช้ ลองดู database topology แต่ละแบบเพื่อดู trade-off สำคัญของมัน

Monolithic Database Topology (Monolithic Database Topology)

database topology แบบแรก และอาจพบบ่อยที่สุดที่ใช้ใน EDA คือ topology แบบ single monolithic database ด้วย topology นี้ ข้อมูลทั้งหมดพร้อมให้ event processor ทุกตัวเข้าถึงได้ผ่านฐานข้อมูลกลางเดียว

ประโยชน์หลักของ monolithic database topology คือ event processor ตัวไหนก็สามารถ query ข้อมูลที่ต้องการได้โดยตรงจากฐานข้อมูล โดยไม่ต้องสื่อสารแบบซิงโครนัสกับ event processor ตัวอื่นเลย นี่เป็นข้อได้เปรียบที่สำคัญ เพราะ event-driven architecture พึ่งพา event processor ที่ decoupled สูงซึ่งสื่อสารกันผ่านการสื่อสารแบบอะซิงโครนัส ใน Figure 15-34 event processor Order Placement สามารถ query ฐานข้อมูล monolithic กลางเพื่อดึงจำนวนสินค้าที่มีอยู่ในสต็อกปัจจุบันและตัวเลือกการจัดส่งของลูกค้าได้เลย

Figure 15-34. With the monolithic database topology, data is available directly from the database (ด้วย Monolithic Database Topology ข้อมูลพร้อมใช้งานได้โดยตรงจากฐานข้อมูล)

แม้ monolithic database topology จะรองรับ decoupling และจำกัดการสื่อสารระหว่าง event processor แต่ก็มีข้อเสียยุ่งยากบางอย่าง อันดับแรกคือด้าน fault tolerance ถ้าฐานข้อมูล monolithic กลางล่มหรือต้องปิดเพื่อบำรุงรักษา event processor ทั้งหมดจะใช้งานไม่ได้

ปัญหาที่สองคือ scalability เนื่องจาก event-driven architecture ใช้การสื่อสารแบบอะซิงโครนัส event processor แต่ละตัวจึง scale ได้อย่างอิสระจากตัวอื่น event channel ทำหน้าที่เป็นจุด backpressure เพื่อให้ event processor แต่ละตัว scale ได้ตามความจำเป็น ไม่ว่า event processor ตัวอื่นจะ scale ด้วยหรือไม่ก็ตาม อย่างไรก็ตาม ถ้า event processor ทั้งหมด query และเขียนไปยังฐานข้อมูลเดียวกันพร้อมกัน ฐานข้อมูล นั้นก็ต้อง scale เพื่อรองรับความต้องการเหล่านี้ ฐานข้อมูลหลายตัวไม่สามารถทำแบบนี้ได้ในระดับ concurrency สูง

ปัญหาที่สามคือ change control เมื่อโครงสร้างฐานข้อมูลเปลี่ยนแปลง (เช่น การลบคอลัมน์หรือ attribute) event processor หลายตัวจะได้รับผลกระทบและต้องประสานงานกัน แม้จะเป็นแค่การเปลี่ยนแปลงฐานข้อมูลครั้งเดียวก็ตาม

สุดท้าย monolithic database topology จะสร้าง architectural quantum เดียวเสมอ เนื่องจากใช้ฐานข้อมูล monolithic ร่วมกัน

Domain Database Topology (Domain Database Topology)

database topology อีกแบบที่เป็นไปได้ภายใน EDA คือ domain database topology ซึ่งจัดกลุ่ม event processor เข้าเป็น domain ต่างๆ โดยแต่ละ domain มีฐานข้อมูลของตัวเอง ( Figure 15-35 )

Figure 15-35. The domain database topology uses a separate database for each domain (Domain Database Topology ใช้ฐานข้อมูลแยกกันสำหรับแต่ละ Domain)

ข้อได้เปรียบหลักของ domain database topology เหนือ monolithic database topology ซึ่งมาจากการแบ่งตาม domain คือ fault tolerance, scalability และ change control ที่ดีกว่า ในตัวอย่างที่แสดงใน Figure 15-35 ถ้าฐานข้อมูล domain การประมวลผลคำสั่งซื้อ (ที่เกี่ยวข้องกับ event processor Order Fulfillment และ Order Shipping ) ล่มหรือใช้งานไม่ได้เนื่องจากการบำรุงรักษา domain การวางคำสั่งซื้อก็ยังคงทำงานได้เต็มที่และรับคำสั่งซื้อต่อไปได้ event channel ที่บรรจุ derived event payment applied จะทำหน้าที่เป็นจุด backpressure จัดคิว event ไว้จนกว่าฐานข้อมูลการประมวลผลคำสั่งซื้อจะพร้อมใช้งานอีกครั้ง เช่นเดียวกันกับ scalability และ change control แต่ละฐานข้อมูล domain ต้องกังวลเรื่องการ scale เฉพาะตาม event processor ของ domain ตัวเองเท่านั้น และมีเพียง event processor ในขอบเขต domain นั้นเท่านั้นที่ต้องเปลี่ยนแปลงถ้าโครงสร้างฐานข้อมูลเปลี่ยน

อย่างไรก็ตาม ลองพิจารณาข้อมูลสองอย่างที่ event processor Order Placement ต้องการ: จำนวนหนังสือที่มีอยู่ในสต็อกและตัวเลือกการจัดส่ง ด้วย domain database topology event processor Order Placement สามารถ query ฐานข้อมูล domain ของตัวเองเพื่อดึงข้อมูลสต็อกหนังสือได้ คล้ายกับที่มันดึงข้อมูลนี้ด้วย monolithic database topology แต่มันต้องเรียก แบบซิงโครนัส ไปยัง event processor Order Shipping เพื่อดึงตัวเลือกการจัดส่ง ทำให้ service เหล่านี้ถูก couple กันแบบซิงโครนัส (ดู Figure 15-36 )

Figure 15-36. Data needed by the Order Placement event processor may require synchronous communication to an event processor in another domain (ข้อมูลที่ Order Placement Event Processor ต้องการอาจต้องใช้การสื่อสารแบบ Synchronous ไปยัง Event Processor ใน Domain อื่น)

สถาปนิกควรพยายามหลีกเลี่ยง synchronous coupling ในสถาปัตยกรรมที่ decoupled และ dynamic สูงอย่าง EDA การเรียกแบบซิงโครนัสส่งผลเสียต่อ fault tolerance และ scalability ซึ่งจะลบล้างประโยชน์หลายอย่างของการใช้ topology นี้ ควรตรวจสอบเสมอว่า domain ต่างๆ ยังคงเป็นอิสระจากกันพอสมควร และลดการเรียกแบบซิงโครนัสระหว่าง service ให้มากที่สุดเท่าที่จะทำได้ ถ้าต้องมีการสื่อสารแบบซิงโครนัสระหว่าง event processor มากเกินไป ควรประเมิน domain boundary ใหม่ รวม domain เข้าด้วยกันเป็นหนึ่งเดียว หรือย้ายไปใช้ monolithic database topology แทน

Dedicated Data Topology (Dedicated Data Topology)

อีกตัวเลือกหนึ่งที่ใช้งานได้ภายใน EDA คือ dedicated database topology ซึ่งในโลก microservices มักเรียกกันว่า pattern database-per-service ด้วย database topology นี้ event processor แต่ละตัวมีฐานข้อมูลเฉพาะของตัวเองใน bounded context ที่แน่นหนา คล้ายกับ microservices (ดู “Data Topologies” ใน Chapter 18 ) topology นี้แสดงไว้ใน Figure 15-37

Figure 15-37. The dedicated database topology of EDA uses a separate database for each event processor (Dedicated Database Topology ของ EDA ใช้ฐานข้อมูลแยกกันสำหรับแต่ละ Event Processor)

ไม่น่าแปลกใจที่ dedicated database topology มีระดับ fault tolerance, scalability และ change control สูงที่สุดในบรรดา topology ที่มีอยู่ทั้งหมด ถ้า event processor หรือฐานข้อมูลล่ม ผลกระทบจะจำกัดอยู่แค่ event processor นั้นตัวเดียว event processor อื่นๆ ทั้งหมดยังทำงานได้ตามปกติ ฐานข้อมูลแต่ละตัวต้อง scale ตามแค่ event processor ตัวเดียวใน bounded context ของตัวเอง ทำให้ topology นี้เป็น topology ที่ scale ได้ดีที่สุดในสามแบบที่กล่าวถึงในหัวข้อนี้ สุดท้าย การเปลี่ยนแปลงโครงสร้างฐานข้อมูลจะส่งผลกระทบเฉพาะ event processor ที่ผูกกับฐานข้อมูลนั้นเท่านั้น

ในด้านลบ ขึ้นอยู่กับ database technology stack ตัวเลือกนี้อาจมีค่าใช้จ่ายสูงมาก แต่บางทีข้อเสียที่ใหญ่ที่สุดคือ synchronous dynamic coupling ระหว่าง event processor เพื่อแสดงให้เห็นข้อเสียนี้ ลองดูข้อมูลสองอย่างที่ event processor Order Placement ต้องการสำหรับการประมวลผล: สต็อกหนังสือและตัวเลือกการจัดส่ง ใน topology นี้ event processor Order Placement จะต้องเรียกแบบซิงโครนัสไปยัง ทั้ง event processor Inventory และ event processor Order Shipment เพื่อดึงข้อมูลที่ต้องการ ทำให้เกิดจุด synchronous coupling ที่แน่นหนาไปทั่วสถาปัตยกรรม (ดังที่แสดงใน Figure 15-38 ) เช่นเดียวกับ domain database topology ให้ระบุความต้องการที่เกี่ยวข้องกับข้อมูลทั้งหมดใน event processor แต่ละตัวก่อนเลือก database topology ตัวเลือกนี้

Figure 15-38. Data needed by the Order Placement event processor may require synchronous communication to other event processors (ข้อมูลที่ Event Processor Order Placement ต้องการอาจต้องใช้การสื่อสารแบบ Synchronous ไปยัง Event Processor อื่น)

dedicated database topology เป็นตัวเลือกที่ดีเมื่อ event processor ส่วนใหญ่พึ่งพาตัวเองเป็นหลัก ต้องการเพียงข้อมูลภายใน bounded context ของตัวเองและฐานข้อมูลที่สอดคล้องกันเท่านั้น ถ้า event processor สื่อสารกันมากเกินไป (ดู “Governance” ) สถาปนิกควรพิจารณาย้ายไปใช้ domain หรือแม้แต่ monolithic database topology เพื่อปรับปรุง performance และ scalability โดยรวม อย่างไรก็ตาม ถ้าสถานการณ์เฉพาะเจาะจงเกี่ยวข้องกับการเปลี่ยนแปลงโครงสร้างฐานข้อมูลบ่อยครั้ง นั่นอาจเป็นเหตุให้ต้อง trade-off ระหว่าง operational characteristic เหล่านี้เพื่อลดจำนวน event processor ที่ได้รับผลกระทบ .