Clean Architecture: Repository Pattern

ในโลกของการพัฒนาซอฟต์แวร์ขนาดใหญ่ การรักษาความสะอาด (Cleanliness) ของโค้ดและโครงสร้างสถาปัตยกรรมเป็นสิ่งสำคัญอย่างยิ่ง Clean Architecture คือแนวทางที่แยกส่วนประกอบทางธุรกิจ (Domain) ออกจากรายละเอียดการนำไปใช้งาน (Implementation Details) เช่น ฐานข้อมูลหรือ UI เพื่อให้ระบบมีความยืดหยุ่นและง่ายต่อการบำรุงรักษา

ส่วนประกอบสำคัญที่ช่วยให้การแยกส่วนนี้เป็นจริงได้คือ Repository Pattern Repository ทำหน้าที่เป็นชั้นนามธรรม (Abstraction Layer) ที่ทำหน้าที่เป็นตัวกลางระหว่าง Use Cases (Business Logic) กับแหล่งข้อมูล (Data Source) โดยไม่ให้ Use Cases ต้องรู้ว่าข้อมูลถูกจัดเก็บไว้ที่ไหน (เช่น PostgreSQL, MongoDB หรือไฟล์) เพียงแค่รู้ว่าต้องเรียกใช้เมธอดอะไรเท่านั้น

Repository Pattern ในบริบทของ PostgreSQL

เมื่อเราใช้ PostgreSQL เป็นฐานข้อมูลหลัก Repository Pattern จะเข้ามาห่อหุ้มการเรียกใช้คำสั่ง SQL ทั้งหมด ทำให้โค้ดส่วนธุรกิจของเราสามารถเรียกใช้เมธอดอย่าง repository.get_user_by_id(123) โดยที่โค้ดนั้นไม่สนใจว่าเบื้องหลังจะเป็นการรันคำสั่ง SELECT * FROM users WHERE id = 123

การจำลองการใช้งาน Repository ด้วย PostgreSQL Function

ในเชิงเทคนิคของ PostgreSQL เราสามารถจำลองการทำงานของ Repository โดยการสร้าง Stored Procedure หรือ Function ที่รับผิดชอบการเข้าถึงข้อมูลเฉพาะส่วนนี้เท่านั้น ตัวอย่างนี้แสดงการสร้างฟังก์ชันที่จำลองการดึงข้อมูลผู้ใช้ (User) ซึ่งเป็นหัวใจของการทำงานของ Repository:

SQL

-- 1. สร้างตารางข้อมูล (Simulated Data Table) --
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    username VARCHAR(100) NOT NULL,
    email VARCHAR(100) UNIQUE
);

-- 2. สร้างฟังก์ชัน Repository (Abstraction Layer) --
CREATE OR REPLACE FUNCTION get_user_by_id(p_user_id INT)
RETURNS TABLE (user_id INT, username VARCHAR, email VARCHAR) AS $$
BEGIN
    RETURN QUERY SELECT
        u.id, u.username, u.email
    FROM
        users u
    WHERE
        u.id = p_user_id;
END;$$
LANGUAGE plpgsql;

-- 3. การเรียกใช้ Repository ผ่าน Use Case (Business Logic)
SELECT * FROM get_user_by_id(1);

จากตัวอย่างข้างต้น, โค้ดส่วน Use Case เพียงแค่เรียกใช้ฟังก์ชัน get_user_by_id() โดยไม่จำเป็นต้องเขียนคำสั่ง SELECT หรือจัดการกับไวยากรณ์ SQL ใดๆ เลย นี่คือการแยกความรับผิดชอบที่สมบูรณ์แบบตามหลัก Clean Architecture

ประโยชน์ของการใช้ Repository Pattern

• Testability: คุณสามารถ Mock (จำลอง) การทำงานของ Repository ได้ง่าย ทำให้การทดสอบ Business Logic ไม่ต้องพึ่งพาการเชื่อมต่อฐานข้อมูลจริง
• Maintainability: หากคุณตัดสินใจเปลี่ยนจาก PostgreSQL ไปใช้ MySQL หรือ NoSQL คุณต้องแก้ไขโค้ดเพียงแค่ในชั้น Repository เท่านั้น ส่วน Use Case และ Domain Model จะไม่ได้รับผลกระทบ
• Isolation: ช่วยให้โค้ดส่วนธุรกิจมีความบริสุทธิ์ (Pure) และมุ่งเน้นไปที่ ‘สิ่งที่ระบบต้องทำ’ ไม่ใช่ ‘วิธีการที่ระบบต้องทำ’

บทสรุป

Repository Pattern คือเครื่องมือทางสถาปัตยกรรมที่ทรงพลังอย่างยิ่งในการนำ Clean Architecture มาใช้จริง เมื่อผสานรวมกับความสามารถของ PostgreSQL เช่น Stored Procedures หรือ Functions มันจะช่วยสร้างชั้นนามธรรมที่แข็งแกร่ง ทำให้ระบบของคุณมีความยืดหยุ่นสูง สามารถรองรับการเปลี่ยนแปลงทางเทคโนโลยีในอนาคตได้อย่างง่ายดาย และทำให้โค้ดของคุณสะอาดและเป็นระเบียบตามมาตรฐานระดับ Senior Architect อย่างแท้จริง