ในโลกของการพัฒนาซอฟต์แวร์ขนาดใหญ่ การรักษาความยืดหยุ่น (Flexibility) และความสามารถในการบำรุงรักษา (Maintainability) คือหัวใจสำคัญของสถาปัตยกรรมที่แข็งแกร่ง หนึ่งในหลักการที่สำคัญที่สุดของ SOLID คือ Dependency Inversion Principle (DIP) ซึ่งเป็นแนวคิดที่ช่วยให้ระบบของเราไม่เกิดภาวะ ‘ผูกติดแน่น’ (Tight Coupling) ระหว่างโมดูลต่างๆ
DIP ไม่ใช่แค่ทฤษฎี แต่คือการปรับเปลี่ยนมุมมองพื้นฐานว่า โมดูลระดับสูง (High-level modules) ที่กำหนดตรรกะทางธุรกิจหลัก ควรจะขึ้นอยู่กับ ‘นามธรรม’ (Abstractions) ไม่ใช่ ‘รายละเอียดเฉพาะเจาะจง’ (Concretions) ของชั้นข้อมูลหรือระบบย่อยใดย่อยหนึ่ง
Dependency Inversion Principle (DIP) คืออะไรในการใช้งานจริง?
ตามหลักการ DIP โมดูลที่ทำงานระดับสูง (เช่น Business Logic) ไม่ควรเรียกใช้คลาสหรือฟังก์ชันที่ผูกติดกับรายละเอียดการทำงานของฐานข้อมูลโดยตรง (เช่น การเรียกใช้ `SELECT * FROM users` เสมอ) แต่ควรเรียกใช้ผ่านอินเทอร์เฟซ (Interface) หรือสัญญา (Contract) ที่กำหนดไว้เท่านั้น
เมื่อเรานำหลักการนี้มาใช้กับระบบที่ใช้ PostgreSQL เราจะสร้างชั้น Repository หรือ Service Layer ที่ทำหน้าที่เป็นตัวกลางในการกำหนดสัญญาการเข้าถึงข้อมูล (Abstraction) ทำให้เมื่อใดที่เราต้องการเปลี่ยนจาก PostgreSQL ไปใช้ NoSQL หรือเปลี่ยน Schema การเข้าถึงข้อมูลก็จะถูกจำกัดอยู่แค่ในชั้นนี้เท่านั้น โดยที่ Business Logic หลักไม่จำเป็นต้องเปลี่ยนแปลงตามไปด้วย
การประยุกต์ใช้ DIP ใน PostgreSQL Context
สมมติว่าเรามีระบบจัดการสินค้า (Product Management) ที่มี Business Logic ที่ต้องการดึงข้อมูลสินค้าเพื่อคำนวณราคารวม การทำตาม DIP คือการไม่ให้ Business Logic ไปเรียกใช้คำสั่ง SQL โดยตรง แต่ให้เรียกใช้ผ่านฟังก์ชันที่ถูกกำหนดให้เป็น ‘สัญญา’ (Contract) ของการทำงาน
ในทางปฏิบัติของ PostgreSQL เราสามารถสร้าง Schema หรือ Function ที่ทำหน้าที่เป็นตัวกลางในการรับประกันว่าข้อมูลที่ส่งออกไปเป็นไปตามรูปแบบที่กำหนด (Abstraction) ไม่ว่าเบื้องหลังจะมีการ Join หรือ Query ที่ซับซ้อนแค่ไหนก็ตาม
SQL
-- 1. สร้าง Abstraction (สัญญา) ของข้อมูลที่ต้องการ (Product View) --
CREATE OR REPLACE VIEW product_abstraction AS
SELECT product_id, product_name, price, stock_level
FROM products
WHERE is_active = TRUE;
-- 2. Business Logic จะเรียกใช้ View (Abstraction) นี้เท่านั้น ไม่รู้ว่าข้อมูลมาจากตารางใด --
SELECT product_name, price
FROM product_abstraction
WHERE product_id = 100;
ในตัวอย่างนี้, `product_abstraction` คือนามธรรม (Abstraction) ที่ Business Logic (ส่วนที่เรียกใช้ View) ต้องพึ่งพา มันไม่สนใจว่า View นี้จะ Query ข้อมูลจากตาราง `products` หรือมีการ Join กับตารางอื่น ๆ กี่ตาราง ตราบใดที่โครงสร้างของ View ยังคงเดิม (สัญญา) ระบบก็จะทำงานได้
สรุป: ประโยชน์ของ DIP ต่อสถาปัตยกรรม
การยึดมั่นใน Dependency Inversion Principle ทำให้โค้ดของเรามีความยืดหยุ่นสูงขึ้นอย่างมาก เมื่อระบบขยายตัวหรือเมื่อเราต้องเปลี่ยนเทคโนโลยีฐานข้อมูล (เช่น เปลี่ยนจาก PostgreSQL เป็น CockroachDB) เราเพียงแค่ปรับเปลี่ยนการใช้งานในชั้น Abstraction (Repository Layer) โดยที่ Business Logic หลักที่อยู่ด้านบนยังคงทำงานได้อย่างสมบูรณ์ นี่คือหัวใจสำคัญของการสร้างสถาปัตยกรรมระดับ Senior Architect ที่แข็งแกร่งและพร้อมสำหรับการเปลี่ยนแปลงในอนาคต