ในโลกของการพัฒนาซอฟต์แวร์ที่ระบบมีความซับซ้อนและมีขนาดใหญ่ขึ้นเรื่อย ๆ การทำความเข้าใจขอบเขตและความสัมพันธ์ของส่วนประกอบต่าง ๆ จึงเป็นหัวใจสำคัญที่กำหนดว่าโครงการจะสามารถเติบโตได้อย่างยั่งยืนหรือไม่ หากปราศจากแผนผังสถาปัตยกรรมที่ชัดเจน ทีมพัฒนาอาจต้องเผชิญกับปัญหา “Spaghetti Code” หรือการพึ่งพาอาศัยกันมากเกินไป (Tight Coupling) ซึ่งทำให้การแก้ไขหรือเพิ่มฟีเจอร์ใหม่เป็นเรื่องที่เสี่ยงและใช้เวลานาน
C4 Model Level 3: การกำหนดขอบเขตของ Component
เมื่อเราพูดถึงการออกแบบสถาปัตยกรรมระดับ Component Diagram (C4 Model Level 3) เรากำลังก้าวข้ามจากการมองภาพรวมของระบบหลัก ๆ ไปสู่การเจาะลึกว่าแต่ละส่วนประกอบ (Component) นั้นถูกแบ่งออกเป็นโมดูลหรือหน่วยงานที่สามารถพัฒนาและ Deploy ได้อย่างอิสระได้อย่างไร การทำเช่นนี้ช่วยให้เรากำหนด “สัญญา” (Contract) ระหว่าง Component ต่าง ๆ อย่างชัดเจน ไม่ว่าจะเป็น API Endpoint, Message Queue หรือ Data Flow ซึ่งเป็นการสร้างขอบเขตความรับผิดชอบ (Boundary) ที่แม่นยำ
การประยุกต์ใช้กับ PostgreSQL
ในบริบทของการใช้ PostgreSQL ซึ่งเป็นระบบฐานข้อมูลเชิงสัมพันธ์ (Relational Database) การกำหนด Component Boundary ใน Level 3 สามารถทำได้โดยการใช้ฟีเจอร์ของ PostgreSQL เช่น **Schema** และ **Stored Procedures/Functions** เพื่อจำลองขอบเขตทางตรรกะ (Logical Boundary) ของโมดูลนั้น ๆ
Component Diagram ที่ดีต้องระบุว่า Component A จะสื่อสารกับ Component B ผ่านช่องทางใด และข้อมูลที่ส่งผ่านคืออะไร เมื่อเราใช้ PostgreSQL เราจะใช้ Schema เพื่อแยกชุดตารางและฟังก์ชันที่เกี่ยวข้องกับโมดูลนั้น ๆ ออกจากกันอย่างชัดเจน ทำให้เกิดการแยกความรับผิดชอบ (Separation of Concerns) ในระดับฐานข้อมูล
ตัวอย่างการสร้าง Component Boundary ด้วย PostgreSQL
สมมติว่าเรากำลังพัฒนาโมดูล ‘Billing’ ซึ่งเป็น Component หนึ่ง เราต้องมั่นใจว่าตารางและฟังก์ชันทั้งหมดที่เกี่ยวข้องกับ Billing จะถูกแยกออกจากโมดูลอื่น ๆ อย่างชัดเจน เราจะใช้คำสั่ง SQL เพื่อสร้าง Schema และกำหนดโครงสร้างข้อมูลที่เป็น ‘สัญญา’ ของโมดูลนี้
SQL
-- 1. สร้าง Schema เพื่อกำหนดขอบเขตของ Component 'billing' (The Boundary) </code><code class="language-sql">CREATE SCHEMA IF NOT EXISTS billing;</code><pre><code class="language-sql">-- 2. สร้างตารางหลักภายใน Schema เพื่อกำหนด Contract ของข้อมูล </code><code class="language-sql">CREATE TABLE billing.transactions (</code><pre><code class="language-sql"> transaction_id UUID PRIMARY KEY,</code><pre><code class="language-sql"> user_id INT NOT NULL,</code><pre><code class="language-sql"> item_list TEXT[] NOT NULL, -- ใช้ Array Type เพื่อเก็บรายการสินค้า</code><pre><code class="language-sql"> amount NUMERIC(10, 2) NOT NULL,</code><pre><code class="language-sql"> created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP</code><pre>
SQL
);</code><pre><code class="language-sql">-- 3. สร้าง Function เพื่อจำลอง API Endpoint หรือ Business Logic </code><code class="language-sql">CREATE OR REPLACE FUNCTION billing.process_payment(p_user_id INT, p_items TEXT[], p_amount NUMERIC)</code><pre><code class="language-sql">RETURNS UUID AS $$</code><pre><code class="language-sql">BEGIN</code><pre><code class="language-sql"> INSERT INTO billing.transactions (transaction_id, user_id, item_list, amount)</code><pre><code class="language-sql"> VALUES (uuid_generate_v4(), p_user_id, p_items, p_amount) RETURNING transaction_id;</code><pre><code class="language-sql"> RETURN NEXT;</code><pre><code class="language-sql">END;</code><pre><code class="language-sql">$$ LANGUAGE plpgsql;
บทสรุป
การออกแบบ Component Diagram ระดับ 3 ไม่ใช่แค่การวาดรูปแผนผัง แต่คือการกำหนด ‘สัญญา’ ทางสถาปัตยกรรมที่ชัดเจน การใช้ Schema และ Function ของ PostgreSQL ช่วยให้เราสามารถบังคับใช้ขอบเขตความรับผิดชอบนี้ได้จริงในระดับโค้ด ทำให้ทีมพัฒนาสามารถทำงานแบบ Microservices ได้อย่างมั่นใจ ลดความเสี่ยงจากการเปลี่ยนแปลงโค้ดในส่วนอื่น (Side Effect) และทำให้ระบบขนาดใหญ่สามารถขยายตัวได้อย่างยั่งยืนและมีประสิทธิภาพสูงสุด