Software​ ​Architecture​ ​คือ​อะไร​ ​และ​เหตุ​ใด​ควร​วาง​โครงสร้าง​ก่อน​ระบบ​เติบโต

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

คำถามที่ควรตอบก่อนโครงสร้างใหญ่

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

ภาพที่ 1: สถาปัตยกรรมที่อ่านได้ควรบอกว่าแต่ละส่วนเป็นเจ้าของงานและข้อมูลใด

ตัวอย่างสมมติ: ระบบรับคำขอ

ระบบมีหน้าเว็บ API ฐานข้อมูล และช่องทางแจ้งเตือน การตัดสินใจสำคัญคือฐานข้อมูลเป็นแหล่งสถานะคำขอหลัก ส่วนการแจ้งเตือนเป็นผลตามหลัง หากส่งแจ้งไม่สำเร็จ คำขอยังต้องอยู่และมีรายการให้ลองใหม่ นี่เป็นการตัดสินใจเชิงสถาปัตยกรรมที่ส่งผลต่อการทดสอบและการดูแล มากกว่าการเลือกจำนวน Server

วางเท่าที่จำเป็นและบันทึกเหตุผล

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

สำหรับรายงาน

ทำแผนภาพบริบทก่อน แล้วซูมเฉพาะส่วนที่เกี่ยวกับโจทย์ แยกเหตุผลที่พิสูจน์แล้วจากสมมติฐานเรื่องการเติบโต อธิบายข้อจำกัดของทางเลือกและวิธีวัดว่าจะต้องเปลี่ยนเมื่อใด

อ่าน Monolith กับ Microservices และ Layered Architecture หรือดู บริการ Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

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

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

แหล่งข้อมูลประกอบ

• Microsoft Learn: Common web application architectures — การจัดขอบเขตและชั้นงาน
• Martin Fowler: Monolith First — ข้อแลกเปลี่ยนของการแยกบริการก่อนมีหลักฐาน