ในฐานะสถาปนิกระบบ (System Architect) การจัดการระบบสีและธีม (Theming) ที่ยืดหยุ่นสูงเป็นหัวใจสำคัญของแอปพลิเคชันสมัยใหม่ โดยเฉพาะการรองรับแนวคิด Dynamic Color (เช่น Material You) ที่สามารถปรับสีตามบริบทหรือรูปภาพได้ทันที
ในการนำแนวคิดนี้มาใช้ในระดับ Backend หรือการกำหนดค่าโครงสร้างข้อมูล (Schema) เราจำเป็นต้องใช้หลักการ **Design Tokens** ซึ่งคือการแยกความหมาย (Semantic) ของค่าสีออกจากค่าสีดิบ (Raw Value) การใช้ PostgreSQL ในการจัดการโครงสร้าง Token นี้ช่วยให้เราสามารถสร้างชั้นการสืบทอด (Inheritance Layer) ของค่าสีได้อย่างเป็นระบบและ Scalable
1. การสร้างโครงสร้าง Token 3 ระดับใน PostgreSQL
สถาปัตยกรรม Token ที่สมบูรณ์แบบจะแบ่งออกเป็น 3 ระดับ เพื่อให้เกิดการแยกชั้นของความหมาย (Layered Abstraction) อย่างชัดเจน:
SQL
-- ===================================================================
-- TIER 1: REFERENCE TOKENS (ค่าสีดิบตาม Palette/HCT Tonal Scale)
-- เก็บค่าสีพื้นฐานที่สุด (เช่น $0-100$ ของสีหลัก)
CREATE TABLE reference_tokens (
token_name VARCHAR(50) PRIMARY KEY, -- เช่น 'blue-500', 'red-100'
hex_value VARCHAR(7) NOT NULL, -- เช่น '#123456'
tone_level INTEGER NOT NULL -- ระดับความเข้ม (0-100)
);
COMMENT ON TABLE reference_tokens IS 'ชั้นที่ 1: ค่าสีดิบที่ถูกกำหนดไว้ล่วงหน้า (Raw Palette Values)';
-- ===================================================================
-- TIER 2: SEMANTIC TOKENS (ความหมายและบทบาทตามบริบท UI & Mode)
-- กำหนดว่าค่าสีใดจะใช้แทนบทบาทใด (เช่น 'primary', 'background-surface')
CREATE TABLE semantic_tokens (
context_key VARCHAR(50) PRIMARY KEY, -- เช่น 'primary', 'surface-background'
light_mode_token_ref VARCHAR(50) REFERENCES reference_tokens(token_name),
dark_mode_token_ref VARCHAR(50) REFERENCES reference_tokens(token_name)
);
COMMENT ON TABLE semantic_tokens IS 'ชั้นที่ 2: การแมปความหมายของสีตามโหมด (Light/Dark Mode)';
-- ===================================================================
-- TIER 3: COMPONENT TOKENS (การใช้งานเฉพาะจุด)
-- กำหนดการใช้งานสุดท้ายของส่วนประกอบ UI (เช่น ปุ่ม, แถบนำทาง)
CREATE TABLE component_tokens (
component_name VARCHAR(50) PRIMARY KEY, -- เช่น 'button-primary', 'nav-active'
semantic_token_ref VARCHAR(50) REFERENCES semantic_tokens(context_key), -- อ้างอิงจาก Tier 2
fallback_hex VARCHAR(7)
);
COMMENT ON TABLE component_tokens IS 'ชั้นที่ 3: การกำหนดค่าสีสุดท้ายสำหรับส่วนประกอบ UI ที่เฉพาะเจาะจง';
2. การทำงานของ Dynamic Color ด้วย PostgreSQL Query
เมื่อระบบต้องการค่าสีสำหรับปุ่มหลัก (Primary Button) ในโหมด Dark Mode เราจะไม่ Query ค่าสีโดยตรง แต่จะ Query ผ่านชั้นความหมาย:
SQL
-- 1. ค้นหา Semantic Token สำหรับ 'primary' ใน Dark Mode
WITH primary_semantic AS (
SELECT dark_mode_token_ref FROM semantic_tokens WHERE context_key = 'primary'
)
-- 2. ดึงค่าสีดิบ (Hex Value) จาก Token Reference
SELECT
rt.hex_value AS final_color_hex
FROM
reference_tokens rt
JOIN
primary_semantic ps ON rt.token_name = ps.dark_mode_token_ref;
-- ตัวอย่างผลลัพธ์: '#B3E0FF' (ค่าสีที่ถูกต้องสำหรับ Primary Button ใน Dark Mode)
กระบวนการนี้ทำให้เราสามารถเปลี่ยน Seed Color (เช่น จากภาพถ่าย) ได้เพียงแค่การอัปเดตค่าใน `reference_tokens` โดยที่โค้ด UI ที่เรียกใช้ `component_tokens` ไม่จำเป็นต้องเปลี่ยนแปลงเลย นี่คือพลังของการแยกชั้นความหมาย (Semantic Separation) ที่ทำได้ด้วยโครงสร้างข้อมูลของ PostgreSQL
บทสรุป: การออกแบบที่ยืดหยุ่นและ Scalable
การใช้ PostgreSQL ในการจัดการ Design Tokens ไม่เพียงแต่ช่วยให้การจัดการค่าสีมีความเป็นระเบียบเท่านั้น แต่ยังช่วยให้เราสร้างระบบที่รองรับการเปลี่ยนแปลงครั้งใหญ่ (เช่น การเปลี่ยน Material Design เวอร์ชัน หรือการเพิ่มโหมด Contrast) ได้อย่างง่ายดายและมีประสิทธิภาพสูงสุด นักพัฒนาสามารถมั่นใจได้ว่าทุกส่วนประกอบ UI จะได้รับค่าสีที่ถูกต้องตามบริบทและโหมดที่กำหนด โดยไม่ต้องพึ่งพา Hardcoded Values อีกต่อไป