ในฐานะ Senior Architect การพัฒนาระบบที่มีความซับซ้อนสูง ไม่ได้หมายถึงแค่การเขียนโค้ดจำนวนมาก แต่หมายถึงการสร้างโค้ดที่มีโครงสร้าง (Structure) ที่แข็งแกร่ง สามารถบำรุงรักษา (Maintainability) และขยาย (Scalability) ได้อย่างง่ายดาย การจัดการข้อมูลในระดับฐานข้อมูล (Database Layer) ก็เช่นกัน เมื่อแอปพลิเคชันเติบโตขึ้น การเขียน SQL Query ที่ซับซ้อนและยาวเหยียดในทุกส่วนของแอปพลิเคชัน จะนำไปสู่ปัญหาที่เรียกว่า “Database Spaghetti Code” ซึ่งทำให้การแก้ไขแม้แต่เงื่อนไขเล็กน้อยกลายเป็นภารกิจที่เสี่ยงต่อการเกิดข้อผิดพลาดสูง
หลักการ Page Object Model (POM) ในบริบทของ PostgreSQL
แนวคิดหลักของ Page Object Model (POM) คือการแยกองค์ประกอบของหน้าจอ (Elements) และพฤติกรรม (Actions) ออกจาก Logic การทดสอบ เพื่อให้โค้ดเทสมีความยืดหยุ่นและไม่เปราะบาง (Brittle) แม้ว่าเราจะไม่ได้ทำงานกับ UI แต่หลักการนี้สามารถนำมาประยุกต์ใช้กับ PostgreSQL ได้อย่างสมบูรณ์ นั่นคือการแยก ‘ตรรกะทางธุรกิจ’ (Business Logic) ออกจาก ‘โค้ดที่เรียกใช้’ (Calling Code) ด้วยการใช้ PostgreSQL Functions, Stored Procedures, หรือ Views
แทนที่จะให้ Application Layer เรียกใช้ Query ที่ซับซ้อนโดยตรง เราควรห่อหุ้มตรรกะเหล่านั้นไว้ใน Database Function (หรือที่เรียกว่า Data Object) Function เหล่านี้จะทำหน้าที่เป็น ‘Page Object’ ของข้อมูล ทำให้เราสามารถเรียกใช้เมธอดที่กำหนดไว้แล้ว (เช่น get_filtered_users(user_id)) โดยไม่ต้องสนใจว่าภายใน Function นั้นมีการ Join ตารางกี่ตาราง หรือมีเงื่อนไข WHERE ที่ซับซ้อนแค่ไหน
การประยุกต์ใช้ Function เพื่อความยั่งยืนของโค้ด
การใช้ Function ช่วยให้เกิดการรวมศูนย์ (Centralization) ของตรรกะทางธุรกิจ เมื่อใดก็ตามที่เงื่อนไขการคำนวณหรือการกรองข้อมูลมีการเปลี่ยนแปลง เราแก้ไขโค้ดเพียงจุดเดียวใน Function นั้นๆ เท่านั้น ไม่ต้องไล่แก้ไข Query ในทุกส่วนของแอปพลิเคชันที่เรียกใช้ข้อมูลชุดนี้
พิจารณาตัวอย่างการสร้าง Function ใน PostgreSQL เพื่อจัดการการคำนวณสถานะสินค้าที่ซับซ้อน โดยใช้หลักการ POM:
SQL
-- 1. สร้าง Function เพื่อจัดการตรรกะทางธุรกิจ (The 'Page Object')
CREATE OR REPLACE FUNCTION calculate_product_status(p_product_id INT, p_inventory_list TEXT) RETURNS TEXT AS $$
BEGIN
-- ตรรกะการตรวจสอบสต็อกที่ซับซ้อน
IF p_inventory_list LIKE '%1,2,3%' THEN
RETURN 'In Stock';
ELSIF p_product_id = 101 THEN
RETURN 'Low Stock';
ELSE
RETURN 'Out of Stock';
END IF;
END;$$
LANGUAGE plpgsql;
-- 2. การเรียกใช้ Function จาก Application Layer (The 'Test Case')
SELECT calculate_product_status(101, '1,2,3');
SELECT calculate_product_status(202, '4,5,6');
จากตัวอย่างข้างต้น Application Layer เพียงแค่เรียกใช้ calculate_product_status(...) เท่านั้น ทำให้โค้ดที่เรียกใช้มีความสะอาด (Clean) และอ่านง่ายมาก แม้ว่าตรรกะภายใน Function จะถูกปรับปรุงหรือเพิ่มเงื่อนไขใหม่ ก็จะไม่ส่งผลกระทบต่อโค้ดที่เรียกใช้เลย
บทสรุป: การยกระดับสถาปัตยกรรมด้วยหลักการ POM
การนำหลักการ Page Object Model มาปรับใช้ในระดับฐานข้อมูลด้วย PostgreSQL Functions ไม่ใช่แค่การเขียนโค้ดที่ดูดี แต่เป็นการยกระดับสถาปัตยกรรมให้มีความทนทาน (Resilient) และง่ายต่อการบำรุงรักษาในระยะยาว การแยก Logic ออกมาเป็นโมดูลที่ชัดเจน ช่วยให้ทีมงานสามารถทำงานได้อย่างอิสระและลดความเสี่ยงในการเกิด Bug ได้อย่างมีนัยสำคัญ ซึ่งเป็นคุณสมบัติสำคัญของระบบระดับ Senior Architect อย่างแท้จริง