Data Topologies (Data Topology)
service-based architecture ให้ตัวเลือกด้าน database topology แก่สถาปนิกมากมาย ยิ่งแสดงให้เห็นความยืดหยุ่นของมัน style นี้มีเอกลักษณ์ตรงที่เป็น distributed architecture ที่รองรับฐานข้อมูล monolithic ได้อย่างมีประสิทธิภาพ อย่างไรก็ตาม ฐานข้อมูล monolithic เดียวนั้นก็สามารถแยกออกเป็นฐานข้อมูลย่อยได้ ถึงขั้นสร้างฐานข้อมูลที่ผูกกับ domain แต่ละตัว (คล้ายกับ microservices) ถ้าใช้ฐานข้อมูลแยกหลายตัว สถาปนิกต้องแน่ใจว่าไม่มี domain service อื่นต้องการข้อมูลในแต่ละฐานข้อมูลนั้น ซึ่งอาจนำไปสู่การสื่อสารระหว่าง domain service ได้ โดยทั่วไปมักเลือกแชร์ข้อมูลมากกว่าการเรียก domain service อื่นใน architectural style นี้ database variant เหล่านี้แสดงอยู่ใน Figure 14-5 .
Figure 14-5. Database topology ของ service-based architecture
แม้ architectural style นี้จะรองรับฐานข้อมูล monolithic แต่การเปลี่ยน schema ของตารางฐานข้อมูล ถ้าทำไม่ถูกต้อง ก็อาจกระทบทุก domain service ได้ นี่ทำให้การเปลี่ยนฐานข้อมูลเป็นงานที่มีต้นทุนสูง เสี่ยงสูง และต้องใช้ความพยายาม การประสานงาน และความน่าเชื่อถือโดยรวมอย่างมาก
ใน service-based architecture class file ที่แชร์กันซึ่งแทน schema ของตารางฐานข้อมูล (เรียกว่า entity object ) มักอยู่ใน shared library แบบ custom ที่ domain service ทั้งหมดใช้ร่วมกัน เช่นไฟล์ JAR หรือ DLL shared library เหล่านี้อาจมี SQL code อยู่ด้วยก็ได้ การสร้าง shared library เดียวที่รวม entity object ทั้งหมดไว้ด้วยกันคือวิธีที่ มีประสิทธิภาพน้อยที่สุด ในการ implement service-based architecture การเปลี่ยนแปลงโครงสร้างตารางฐานข้อมูลใด ๆ ก็ต้องเปลี่ยน library ของ entity object ที่เกี่ยวข้องด้วย ซึ่งหมายถึงต้องเปลี่ยนและ redeploy service ทุกตัว ไม่ว่า service นั้นจะเข้าถึงตารางที่เปลี่ยนแปลงจริงหรือไม่ก็ตาม การทำ versioning ให้ shared library ช่วยบรรเทาปัญหานี้ได้ แต่ก็ยังยากที่จะรู้ว่าการเปลี่ยนตารางนั้นจะกระทบ service ใดบ้างโดยไม่ต้องวิเคราะห์แบบละเอียดด้วยมือ สถานการณ์นี้ ซึ่งถือเป็น antipattern ใน service-based architecture แสดงอยู่ใน Figure 14-6 .
Figure 14-6. การใช้ shared library เดียวสำหรับ database entity object ส่งผลกระทบต่อ service ทั้งหมดเมื่อมีการเปลี่ยนแปลง และถือเป็น antipattern ใน service-based architecture
วิธีหนึ่งในการลดผลกระทบและความเสี่ยงจากการเปลี่ยนแปลงฐานข้อมูลคือการแบ่งฐานข้อมูลออกเป็นส่วนย่อยเชิง logical และแทนการแบ่งนั้นด้วย shared library แยกกัน สังเกตว่าใน Figure 14-7 ฐานข้อมูลถูกแบ่งเชิง logical ออกเป็นห้า domain แยกกัน: common, customer, invoicing, order และ tracking domain service จะใช้ shared library ห้าตัวที่ตรงกับส่วนแบ่งเชิง logical ในฐานข้อมูล ด้วยเทคนิคนี้ การเปลี่ยนแปลงใด ๆ ที่สถาปนิกทำกับตารางภายใน logical domain ใดตัวหนึ่ง (ในกรณีนี้คือ Invoicing ) จะตรงกับ shared library ที่มี entity object ที่เกี่ยวข้อง (และอาจรวมถึง SQL ด้วย) มีเพียง service ที่ใช้ shared library นั้นเท่านั้นที่จะได้รับผลกระทบ ไม่มี service อื่นได้รับผลกระทบจากการเปลี่ยนแปลงนี้ จึงไม่จำเป็นต้องทดสอบและ redeploy service เหล่านั้นใหม่
Figure 14-7. การใช้ shared library หลายตัวสำหรับ database entity object
ใน Figure 14-7 ฐานข้อมูลมี domain Common และ shared library common_entities_lib ที่เกี่ยวข้อง ซึ่งถูกใช้โดย service ทั้งหมด นี่เป็นกรณีที่ค่อนข้างพบบ่อย เนื่องจากตารางเหล่านี้เป็นตารางร่วมของ service ทั้งหมด การเปลี่ยนแปลงตารางเหล่านี้ต้องประสานงานกับ service ทุกตัวที่เข้าถึงฐานข้อมูลที่แชร์กัน วิธีหนึ่งในการลดผลกระทบข้างเคียงที่อาจลุกลามจากการเปลี่ยนแปลงตารางเหล่านี้ (และ entity object กับ domain service ที่เกี่ยวข้อง) คือการล็อก common entity object ไว้ใน version control system (ถ้ามี) และอนุญาตให้เฉพาะทีมฐานข้อมูลเท่านั้นที่ทำการเปลี่ยนแปลงได้ วิธีนี้ช่วยควบคุมการเปลี่ยนแปลงและเน้นย้ำความสำคัญของการเปลี่ยนแปลงตารางร่วมที่ใช้โดย service ทั้งหมด
Tip (เคล็ดลับ)
เพื่อควบคุมการเปลี่ยนแปลงฐานข้อมูลใน service-based architecture ให้ดีขึ้น ให้แบ่งส่วนเชิง logical ในฐานข้อมูลให้ละเอียด (fine-grained) ที่สุดเท่าที่จะทำได้—ในขณะที่ยังคงรักษา data domain ที่นิยามไว้อย่างชัดเจน