ในฐานะ Senior Architect การออกแบบระบบที่ยืดหยุ่นและบำรุงรักษาง่ายคือหัวใจสำคัญ Clean Architecture และ Onion Architecture คือแนวคิดที่ช่วยแก้ปัญหาการพึ่งพา (Dependency) ระหว่างชั้นต่างๆ ของระบบ โดยมีเป้าหมายคือการแยก Business Rules (Domain) ออกจากรายละเอียดทางเทคนิค (Infrastructure) เช่น ฐานข้อมูล
เมื่อเราใช้ PostgreSQL เป็นระบบฐานข้อมูลหลัก การนำหลักการนี้มาใช้หมายความว่า Domain Layer ของเราไม่ควรทราบว่าข้อมูลถูกจัดเก็บใน PostgreSQL, MySQL, หรือแม้แต่ไฟล์ CSV แต่ควรทราบเพียงแค่ ‘สัญญา’ (Contract) ผ่าน Interface หรือ Abstract Class เท่านั้น
หลักการทำงานของ Onion Architecture กับ PostgreSQL
หัวใจสำคัญคือการกำหนดให้ Domain Layer เป็นศูนย์กลาง (Core) ซึ่งจะกำหนด Use Cases และ Business Rules ต่างๆ ส่วน Infrastructure Layer คือส่วนที่รับผิดชอบในการติดต่อกับ PostgreSQL โดยเฉพาะการจัดการ Repository Pattern
ในเชิงปฏิบัติ เมื่อเราต้องการบันทึกข้อมูลผู้ใช้ (User) เราจะสร้าง Interface ใน Domain Layer เช่น UserRepository ซึ่งกำหนดเมธอด save(user) จากนั้นใน Infrastructure Layer (ซึ่งเป็น PostgreSQL Implementation) จะรับผิดชอบการแปลง Object ของ Domain ให้เป็นคำสั่ง SQL และดำเนินการผ่าน PostgreSQL Connection
SQL
-- 1. Domain Layer (Define the Contract) --
-- (No SQL here, but conceptually defines the interface)
-- 2. Infrastructure Layer (PostgreSQL Implementation) --
CREATE TABLE users (
id SERIAL PRIMARY KEY,
username VARCHAR(100) UNIQUE NOT NULL,
email VARCHAR(100) NOT NULL
);
-- Function simulating the repository interaction
CREATE OR REPLACE FUNCTION create_user_record(p_username VARCHAR, p_email VARCHAR)
RETURNS INTEGER AS $$
BEGIN
INSERT INTO users (username, email) VALUES (p_username, p_email)
RETURNING id;
END;$$
-- Usage Example (Calling the service via the repository function)
SELECT create_user_record('alice', '[email protected]');
จากตัวอย่างข้างต้น create_user_record คือการนำ PostgreSQL มาใช้เป็นกลไกในการเก็บข้อมูลตามคำสั่งของ Business Logic ที่อยู่ภายนอก (Domain) ทำให้หากวันหน้าเราเปลี่ยนไปใช้ NoSQL Database เราเพียงแค่เปลี่ยน Implementation ของ Repository โดยที่ Business Logic หลักไม่จำเป็นต้องเปลี่ยนแปลงเลย
ประโยชน์ในการพัฒนาด้วย PostgreSQL
การยึดหลัก Clean Architecture ช่วยให้เราใช้ประโยชน์จากคุณสมบัติเฉพาะของ PostgreSQL เช่น Transaction Management (ACID) ได้อย่างมีประสิทธิภาพในชั้น Infrastructure โดยที่ชั้น Domain ยังคงบริสุทธิ์และมุ่งเน้นไปที่กฎทางธุรกิจเท่านั้น ทำให้โค้ดของเรามีความทนทานต่อการเปลี่ยนแปลงของเทคโนโลยีฐานข้อมูล (Database Agnostic) สูงสุด
บทสรุป
การผสาน Clean Architecture เข้ากับ PostgreSQL อย่างถูกต้อง ไม่ใช่แค่การเขียน SQL ที่ดี แต่คือการออกแบบสถาปัตยกรรมที่แยกความรับผิดชอบอย่างชัดเจน ทำให้ระบบของเราสามารถขยายตัว (Scalability) และรองรับการเปลี่ยนแปลงทางธุรกิจได้อย่างรวดเร็วและมีเสถียรภาพในระดับ Senior Architect