The C4 Model for Visualising Software Architecture

Boonsong Srithong

8 min read

·

Oct 6, 2026

--

Share

Working Software over Comprehensive Documentation (เราให้คุณค่ากับซอฟต์แวร์ที่ใช้งานได้ มากกว่าเอกสารที่ครอบคลุม) — Agile Manifesto

“ไม่ได้หมายความว่า Documentation ไม่สำคัญหรือไม่ต้องทำ”

Press enter or click to view image in full size

กระบวนการสร้างซอฟต์แวร์นั้น ไม่ได้เป็นเพียงแค่การแบ่งงานกันทำ แต่เป็นการนำความเชี่ยวชาญและ Skills ของแต่ละคนมาประกอบเข้าด้วยกัน เพื่อสร้าง Product ที่ตอบโจทย์ สามารถส่งมอบคุณค่าและประสบการณ์ที่ดีที่สุดให้กับ “คนใช้งาน”

ยิ่งในการพัฒนา Product ที่มี Stakeholder เกี่ยวข้องอยู่เป็นจำนวนมาก แต่ละคนย่อมมีบทบาท ความรับผิดชอบ ความเชี่ยวชาญ ทักษะ และจุดที่ให้ความสำคัญแตกต่างกันออกไป การทำให้ทุกคนมี Shared Goal ร่วมกันและมองเห็นเป้าหมายเดียวกันจึงเป็นสิ่งสำคัญ

The C4 Model

ย้อนกลับไปตอนที่เรียนมหาวิทยาลัย ผมได้เรียนรู้เรื่อง Software Development และรู้จักแนวทางอย่าง Waterfall, Iterative, Spiral และ V-Model ได้ฝึกทำ Project Plan เขียน Flowchart รวมถึง UML หลากหลายรูปแบบ เช่น Class Diagram, Use Case Diagram, Deployment Diagram และ Sequence Diagram เพื่อทำ Documentation สำหรับนำเสนอ Final Project

ตอนนั้นจำได้ว่านอกจาก VS Code, Angular และ .NET Core แล้ว ก็มี Draw.io กับ Microsoft Word นี่แหละที่สนิทกัน

พอเริ่มทำงานจริง ผมก็มีโอกาสหยิบ Diagram เหล่านี้มาใช้เป็นครั้งคราว ขึ้นอยู่กับสถานการณ์ เช่น

• Use Case Diagram: ใช้คุยกับฝั่ง Business และ Product Owner เพื่อให้เห็นภาพตรงกันในระดับ High-level ว่าระบบทำอะไรได้บ้าง และใครคือผู้ใช้งาน โดยยังไม่ต้องลงรายละเอียดเชิง Technical
• Sequence Diagram: ใช้คุยกันภายในหรือข้ามทีม Development เพื่อตกลงเรื่อง API Flow, ลำดับการเรียก Service หรือการส่งข้อมูลระหว่างระบบ
• Deployment / Network Diagram: ใช้คุยกับทีม Infrastructure เพื่อเตรียมความพร้อมของระบบ

แต่ถ้าเป็นการเล่าเรื่อง Software Architecture ในภาพรวม Diagram ที่ผมหยิบมาใช้บ่อยขึ้นเรื่อย ๆ คือ C4 Model

C4 Model คือแนวทางสำหรับการสร้างแบบจำลองและสื่อสาร Software Architecture ผ่านระดับของ Abstraction ที่กำหนดร่วมกัน โดยมองระบบผ่าน 4 ระดับ ได้แก่ Software System, Container, Component และ Code

แนวคิดนี้เกิดจากปัญหาที่ Simon Brown พบในการทำงานจริงว่า Diagram ด้าน Software Architecture มักไม่มีรูปแบบหรือระดับรายละเอียดที่ชัดเจน แต่ละทีมและแต่ละคนวาด Diagram ในแบบของตัวเองได้ ทำให้ผู้อ่านต้องตีความว่าแต่ละกล่อง เส้น หรือสัญลักษณ์หมายถึงอะไร รวมถึงไม่ชัดเจนว่า Diagram นั้นกำลังอธิบายระบบในระดับใด

Simon Brown เสนอให้เล่าระบบเดียวกันผ่านระดับรายละเอียดที่ต่างกัน เริ่มจากภาพกว้างที่เห็นว่าระบบอยู่ตรงไหน ใครใช้งาน และเชื่อมต่อกับระบบใดบ้าง แล้วค่อยซูมเข้าไปดูรายละเอียด

ลองนึกถึงสถานการณ์ที่ฝนตกต่อเนื่องหลายวัน จนหลายพื้นที่ในกรุงเทพฯ และปริมณฑลเกิดน้ำท่วม หากเราต้องวางแผนเดินทางไปกินข้าวที่ห้างแถวบ้าน เราอาจเริ่มจากแผนที่ภาพรวมเพื่อดูว่าพื้นที่ไหนได้รับผลกระทบบ้าง ก่อนจะค่อย ๆ ซูมเข้าไปดูถนน เส้นทาง และจุดที่มีน้ำท่วมจริง เพื่อเลือกเส้นทางที่เหมาะสม

Press enter or click to view image in full size

การอธิบาย Software Architecture ก็คล้ายกัน บางครั้งเราอาจต้องการเห็นเพียงว่า Product นี้เชื่อมต่อกับระบบใดบ้าง แต่ในบางสถานการณ์ก็ต้องซูมลึกลงไปถึง Application, Service, Database หรือ Code เพื่อทำความเข้าใจรายละเอียดของ Implementation

Internet Banking System

สำหรับบทความนี้ เราจะใช้ Internet Banking System จากหนังสือ The C4 Model เป็นตัวอย่าง ระบบนี้ช่วยให้ลูกค้าเข้าถึงบริการธนาคารผ่านช่องทางออนไลน์ ตั้งแต่ Sign-in เพื่อยืนยันตัวตน ตรวจสอบยอดเงินและรายการบัญชี ดูหรือดาวน์โหลด Statement ไปจนถึงทำรายการชำระเงิน

ระบบจะทำงานกับ Core Banking System เพื่ออ่านข้อมูลบัญชีและดำเนินการด้านธุรกรรม ส่วนการยืนยันตัวตน การแจ้งผลการทำรายการ หรือการแจ้งเตือนเหตุผิดปกติ จะสื่อสารกับลูกค้าผ่าน Email

จากตัวอย่างนี้ เราจะค่อย ๆ ซูมดู Internet Banking System ในแต่ละระดับของ C4 Model เพื่อเห็นว่าระบบเดียวกันถูกอธิบายได้อย่างไรเมื่อระดับรายละเอียดเปลี่ยนไป

C1: System Context Diagram

System Context Diagram (C4 Model Level 1) คือภาพรวมระดับสูงสุดที่แสดงบริบทโดยรอบของ Software System เพื่อกำหนดขอบเขต ให้ทุกคนเห็นภาพตรงกันก่อนลงรายละเอียดเชิงเทคนิค ช่วยป้องกันความเข้าใจสับสนเรื่องความรับผิดชอบของระบบ

Intent

System Context Diagram ช่วยตอบคำถามพื้นฐานของระบบดังนี้

• Software System ที่เรากำลังสร้างหรือดูแลคืออะไร
• ระบบนี้มีหน้าที่หรือคุณค่าหลักอะไร
• คนกลุ่มใดใช้งาน และใช้ระบบเพื่อบรรลุเป้าหมายอะไร
• ระบบต้องรับข้อมูลจาก หรือส่งข้อมูลไปยัง Software Systems ใด
• อะไรอยู่ในความรับผิดชอบของทีม และอะไรเป็น Dependency ภายนอก

Example

สำหรับระบบ Internet Banking เริ่มจากการกำหนดขอบเขตโดยวาง Internet Banking System ไว้ตรงกลางเพื่อเป็นระบบสำหรับตรวจสอบบัญชีและทำธุรกรรมออนไลน์ จากนั้นระบุผู้ใช้งานคือ Personal Banking Customer ที่เข้ามาดูยอดเงินและทำรายการ พร้อมเชื่อมโยงไปยังระบบภายนอกที่จำเป็นต้องพึ่งพา ได้แก่ Core Banking System ซึ่งเป็นระบบหลักที่จัดการข้อมูลบัญชีและธุรกรรม และ Amazon SES เพื่อใช้สำหรับส่ง Email

Content

• People (Users / Actors): ผู้ใช้งานหรือ Persona ที่ใช้ระบบ เช่น Personal Banking Customer (ลูกค้าเข้ามาดูยอดเงินและโอนเงิน) หรือ Customer Service Staff ควรระบุ Role และวัตถุประสงค์สั้น ๆ มากกว่าชื่อบุคคล
• Software Systems: ระบบที่เรากำลังอธิบาย และ External Systems เช่น Core Banking System หรือ Amazon SES ควรใช้ชื่อเต็มและคำอธิบายที่ชัดเจน หลีกเลี่ยง Code Name หรืออักษรย่อเฉพาะกลุ่ม
• Relationships: เส้นเชื่อมพร้อมลูกศรและข้อความอธิบายเจตนาเชิงธุรกิจ เช่น “ดึงข้อมูลบัญชีและส่งคำสั่งโอนเงิน” หรือ “ส่ง Email ยืนยันตัวตน” ใน C1 ไม่จำเป็นต้องลงรายละเอียด Protocol (เช่น REST, JSON, Kafka) ในระดับนี้

C2: Container Diagram

เมื่อ System Context Diagram ทำให้เราเห็นว่า Internet Banking System อยู่ตรงไหนและเชื่อมต่อกับโลกภายนอกอย่างไร ขั้นต่อมาก็เหมือนการวางสองนิ้วบนกล่อง Internet Banking System แล้ว “ถ่างนิ้ว” เพื่อซูมเข้าไปดูว่า ภายในกล่องใบนี้มีอะไรซ่อนอยู่บ้าง

Container Diagram ไม่ได้หมายถึง Docker Container ใน C4 คำว่า Container หมายถึง Application หรือ Data Store ที่เป็นส่วนประกอบหลักภายใน Software System เช่น Web Application, Mobile Application, Backend API, Database, Message Broker, File Store หรือ Batch Process

Intent

Container Diagram ใช้อธิบายว่า ภายใน Software System หนึ่งระบบประกอบด้วย Application และ Data Store อะไรบ้าง แต่ละส่วนรับผิดชอบอะไร ใช้ Technology ใด และสื่อสารกันอย่างไร

คำถามที่ภาพนี้ควรตอบได้ เช่น

• ภายในระบบมี Application หรือ Data Store อะไรบ้าง
• ผู้ใช้เข้าระบบผ่านส่วนใด
• ส่วนใดรับผิดชอบ Business Logic
• ข้อมูลถูกเก็บอยู่ที่ไหน
• Container แต่ละตัวติดต่อกันและติดต่อกับ External System อย่างไร
• Technology หรือ Protocol สำคัญที่มีผลต่อการออกแบบคืออะไร

Example

เริ่มจาก Web UI ที่ทำงานบนหน้าเบราว์เซอร์ของลูกค้าเพื่อแสดงผลและรับคำสั่ง โดยมี Web Server หรือ CDN คอยเสิร์ฟไฟล์ HTML, CSS และ JavaScript ให้ จากนั้น Web UI จะส่งคำขอไปยัง Backend API ซึ่งทำหน้าที่ตรวจสอบสิทธิ์และจัดการ Business Logic ทั้งหมด

Backend นี้จะทำหน้าที่ทั้งการอ่านและเขียนข้อมูลการตั้งค่าผู้ใช้ใน User Database ของระบบเอง เก็บหรือโหลดไฟล์เอกสารจาก Statement Store (เช่น S3 Bucket) รวมไปถึงการเชื่อมต่อกับ Core Banking System เพื่อดึงข้อมูลบัญชี และเรียกใช้ Amazon SES เพื่อส่ง Email

ภาพรวมนี้จะช่วยให้ทีมพัฒนาและทีม Operations เห็นโครงสร้างระบบ เส้นทางการเชื่อมต่อ และเทคโนโลยีที่ใช้ในแต่ละจุดที่ต้องนำไป Deploy และดูแลร่วมกัน

Press enter or click to view image in full size

Content

• Software System Boundary: เส้นขอบเขตของระบบที่กำลังอธิบาย (เช่น กล่อง Internet Banking System ที่ถูกขยายออก)
• Containers: หน่วยประมวลผลหรือแหล่งเก็บข้อมูลที่ทำงานได้ด้วยตัวเอง เช่น Web Application (React/Angular), Mobile App (iOS/Android), Backend API (Java/Spring Boot, Node.js), Database (MySQL, PostgreSQL, MongoDB) หรือ Message Broker แต่ละกล่องต้องระบุ ชื่อ, หน้าที่ และเทคโนโลยีที่ใช้
• Relationships: เส้นเชื่อมโยงระหว่าง Container และระบบภายนอก โดยในระดับนี้ต้องระบุ Protocol/Technology เพิ่มเติม เช่น “ดึงข้อมูลผ่าน JSON/HTTPS” หรือ “อ่าน/เขียนข้อมูลผ่าน SQL”
• People & External Systems: ผู้ใช้และระบบภายนอกยังคงแสดงไว้เพื่อให้เห็นบริบทต่อเนื่องจาก Context Diagram ว่าเชื่อมต่อเข้ามาที่ Container ตัวไหน

Tips

ใน C4 Model การตัดสินว่าสิ่งใดเป็น Container หรือ Software System ไม่ควรดูจากชื่อ Technology หรือ Cloud Service เพียงอย่างเดียว แต่ต้องดูว่าอยู่ภายในขอบเขตของ Software System ที่เรากำลังอธิบายหรือไม่ เช่น หากเรากำลังทำ Container Diagram ของ Internet Banking

• Statement Store บน Amazon S3: สามารถแสดงเป็น Container ได้ หาก Bucket นี้เป็นส่วนหนึ่งของสถาปัตยกรรมภายใน และระบบใช้มันเป็น Data Store สำหรับจัดเก็บ Statement โดยตรง (ทีมเราเป็นคนจัดการโครงสร้างและข้อมูลเอง)
• Amazon SES: ควรแสดงเป็น External Software System เพราะเป็นระบบภายนอกที่ Internet Banking เพียงแค่เรียกใช้เพื่อส่ง Email โดยที่เราไม่ได้สนใจหรือเข้าไปจัดการโครงสร้างการทำงานภายในของ SES

ดังนั้นความแตกต่างสำคัญไม่ได้อยู่ที่ว่า S3 หรือ SES เป็นบริการของ AWS แต่อยู่ที่ Boundary ของ Software System ที่เรากำลัง Model

C3: Component Diagram

Component Diagram (C4 Model Level 3) คือภาพที่ซูมเข้าไปภายใน Container หนึ่งตัว เพื่ออธิบายว่ากลุ่มโค้ดภายในแบ่งความรับผิดชอบกันอย่างไร ในตัวอย่างนี้เราจะเปิดดู Backend API ของ Internet Banking System

คำว่า Component ใน C4 ไม่ได้หมายถึงหน่วยเล็ก ๆ อย่าง Class, File หรือ @Component ของ Framework

Component คือกลุ่มของ Module ที่ถูกจัดกลุ่มรวมตามความรับผิดชอบและทำงานร่วมกันผ่าน Interface ที่ชัดเจน หากใครเคยอ่าน Fundamentals of Software Architecture แนวคิดนี้ใกล้เคียงกับ Logical Component

ตัวอย่างจาก Internet Banking Backend ในภาพ:

• Accounts Summary API: รับผิดชอบการให้ข้อมูลรายการบัญชีของลูกค้า
• Sign-in API: รับคำขอ Login และคืน Authentication Token
• Statement API: รับคำขอเกี่ยวกับ Account Statement
• Security: ตรวจสอบ Credential และ Authentication Token
• Statement: โหลด Statement ที่มีอยู่ หรือสร้าง Statement ใหม่
• Email: รับผิดชอบการส่ง Email ผ่าน Email Provider
• Core Banking System Adapter: แปลง Request/Response ระหว่าง Backend กับ Core Banking System

Intent

Component Diagram แสดงการแตก Container หนึ่งตัวออกเป็น Components เพื่อให้เห็นโครงสร้างระดับสูงของ Application และการทำงานร่วมกันของโค้ดภายใน

คำถามที่ภาพนี้ควรตอบได้ เช่น

• Container ถูกแบ่งออกเป็น Components ใดบ้าง
• แต่ละ Component รับผิดชอบอะไร
• Components ติดต่อและทำงานร่วมกันอย่างไร
• Component เหล่านั้นใช้ Framework หรือ Library สำคัญอะไรบ้างในการพัฒนา
• เมื่อต้องเพิ่ม Feature ใหม่ Developer ควรไปแก้ Code ที่ส่วนใด

Example

ภายใน Backend API ของ Internet Banking มี API Components เช่น Sign-in API, Accounts Summary API และ Statement API สำหรับรับคำขอจาก Web UI

API เหล่านี้ใช้ Security Component เพื่อตรวจสอบ Credentials หรือ Token ก่อนทำงานต่อ จากนั้นจึงเรียก Component ที่รับผิดชอบ Use Case นั้นโดยตรง เช่น Statement Component สำหรับค้นหา สร้าง และจัดเก็บเอกสาร Statement

เมื่อจำเป็นต้องเข้าถึงข้อมูลบัญชี Components ภายในจะเรียกผ่าน Core Banking System Adapter โดย Adapter ทำหน้าที่ Encapsulate รายละเอียดของ Integration เช่น Protocol, Data Format และ Mapping ทำให้ Components อื่นไม่จำเป็นต้องรับรู้รายละเอียดของระบบภายนอก

ส่วนการส่ง Email จะผ่าน Email Component ซึ่งเป็นตัวกลางในการติดต่อ Amazon SES ทำให้ API แต่ละตัวไม่ต้องรับรู้รายละเอียดของ Email Provider โดยตรง

Press enter or click to view image in full size

Content

• People, Software Systems และ Containers: นำองค์ประกอบที่เกี่ยวข้องจาก Container Diagram มาแสดงซ้ำ เพื่อให้คนอ่านเห็นบริบทต่อเนื่องจากภาพก่อนหน้า
• Components: กลุ่มของ Code ที่เกี่ยวข้องกันภายใน Container เดียว แต่ละกล่องควรระบุชื่อ, Technology หลัก และคำอธิบายความรับผิดชอบ โดยโครงสร้างควรสะท้อนรูปแบบ Architecture ที่ใช้จริง เช่น Layered Architecture หรือ Ports and Adapters
• Container Boundary: เส้นขอบที่ระบุชัดว่า Components เหล่านี้อยู่ภายใน Container ใด
• Software System Boundary: อาจแสดงเพิ่มเพื่อให้เห็นว่า Container นั้นเป็นส่วนหนึ่งของ Software System ใด
• Relationships: ลูกศรแบบมีทิศทาง พร้อมข้อความอธิบายความสัมพันธ์ เช่น validates token using หรือ reads data from หากเป็นการสื่อสารข้าม process จึงค่อยระบุ protocol สำคัญ เช่น JSON/HTTP หรือ gRPC

C4: Code Diagram

Code Diagram คือระดับสุดท้ายของ C4 Model ใช้ซูมเข้าไปดูรายละเอียดการ Implementation ภายใน Component หนึ่งตัว เช่น Class, Interface, Function และความสัมพันธ์ระหว่างกัน

ระดับนี้เหมาะกับ Component ที่มีความซับซ้อน หรือมี Pattern และโครงสร้างภายในที่ทีมจำเป็นต้องเข้าใจร่วมกัน มากกว่าการนำไปสร้าง Class Diagram เพื่อครอบคลุมทั้ง Application

อย่างไรก็ตาม ยิ่ง Diagram ลงรายละเอียดใกล้กับ Code มากเท่าไร ก็ยิ่งต้องแก้ตาม Code บ่อยขึ้นเท่านั้น เพราะ Code มีการเปลี่ยนแปลงอยู่ตลอด หากไม่มีการอัปเดต Diagram ให้ทัน ก็มีโอกาสสูงที่ภาพในเอกสารจะไม่ตรงกับระบบจริง

สิ่งที่ควรคำนึงอยู่เสมอคือ Diagram ไม่ได้วาดเสร็จแล้วจบไป แต่ยังมี Cost ในการ Maintain ให้สอดคล้องกับระบบจริงด้วย ส่วนตัวผมมองว่าใน Level 4 นี้ การเปลี่ยนไปให้ความสำคัญกับ Living Documentation อย่างการเขียน Unit Test, Integration Test, E2E Test หรือพูดง่าย ๆ คือการทำ Automated Test ต่าง ๆ จะเป็นสิ่งที่คุ้มค่ากับ Cost ที่ต้องจ่ายไปมากกว่า

Intent

Code Diagram แสดงโครงสร้างของ Code ภายใน Component เดียว เพื่อให้เห็นว่า Component นั้นถูกแบ่งออกเป็นส่วนประกอบระดับ Code อย่างไร ส่วนใดเป็น Public API ที่เปิดให้ภายนอกเรียกใช้ และส่วนใดเป็นรายละเอียดภายในของ Implementation รวมถึงช่วยประเมินความซับซ้อนของ Component ได้

Code Diagram ช่วยตอบคำถามพื้นฐานของระบบดังนี้

• Component นี้ถูกแบ่งออกเป็น Code-level building blocks อะไรบ้าง
• ส่วนใดเป็น Public API ที่เปิดให้ Components อื่นเรียกใช้
• ส่วนใดเป็นรายละเอียดภายในของ Implementation
• Component นี้มีขนาดและความซับซ้อนระดับใด

Example

จาก Component Diagram ก่อนหน้า เราซูมเข้าไปที่ Core Banking System Adapter ซึ่งทำหน้าที่เชื่อม Backend API กับ Core Banking System

Component นี้เปิด Interface ชื่อ CoreBankingSystemAdapter เป็น Contract สำหรับให้ Component อื่นภายใน Backend เรียกใช้งาน โดยมี CoreBankingSystemAdapterImpl เป็น Implementation ที่จัดการขั้นตอนการ Integration ภายใน

เมื่อมีการเรียก getBankAccounts(customerId) ตัว Implementation จะสร้าง BankAccountsRequest เพื่อแปลงข้อมูลเป็น XML และใช้ CoreBankingSystemConnection สำหรับส่ง Request และรับ Response จาก Core Banking System จากนั้น BankAccountsResponse จะทำหน้าที่แปลง XML Response กลับมาเป็นข้อมูลในรูปแบบที่ Application เข้าใจ

Press enter or click to view image in full size

Content

• Code-level Building Blocks: องค์ประกอบตามภาษาที่ใช้ เช่น Class, Interface, Object, Function, Package หรือ Namespace
• Public Interface: ส่วนที่ Component เปิดให้ Components อื่นเรียกใช้ เช่น Interface หรือ Public Class
• Internal Implementation: Class หรือ Function ที่ใช้ทำงานภายใน Component และไม่ควรถูกเรียกโดยตรงจากภายนอก
• Relationships: ความสัมพันธ์ระหว่าง Code Elements เช่น implements, depends on, creates หรือ calls
• Only the Necessary Detail: เลือกแสดงเฉพาะ Properties และ Methods ที่ช่วยเล่าเรื่องของ Component ไม่จำเป็นต้องใส่ทุกสิ่งที่ IDE สร้างออกมา

Code Diagram ไม่จำเป็นต้องแสดงทุก Property หรือทุก Method เลือกใส่เฉพาะรายละเอียดที่ช่วยอธิบาย Pattern หรือแนวทางการต่อยอด Component นั้นได้

You Don't Need All Four Levels

C4 Model มี 4 ระดับ แต่ไม่ได้หมายความว่าทุกระบบต้องมี Diagram ครบทั้ง 4 ระดับเสมอไป

สำหรับทีมส่วนใหญ่ System Context Diagram และ Container Diagram มักเพียงพอ เพราะช่วยให้เห็นขอบเขตของระบบ, ผู้ใช้, Dependencies, Applications และ Data Stores ที่ต้องพัฒนาและดูแล

Component Diagram ค่อยมีความจำเป็นเมื่อ Container หนึ่งตัวเริ่มซับซ้อน มีหลายความรับผิดชอบ หรือทีมต้องสื่อสารโครงสร้างภายในของ Codebase ร่วมกัน ส่วน Code Diagram เหมาะกับ Component ที่สำคัญหรือซับซ้อนเป็นพิเศษ เพราะรายละเอียดระดับ Class และ Interface มักหาอ่านได้จาก Code หรือ IDE อยู่แล้ว

Notation

C4 Model ไม่ได้บังคับให้ใช้สี กล่อง หรือสัญลักษณ์แบบใดแบบหนึ่ง จะใช้กล่องสี่เหลี่ยม, UML, ArchiMate หรือรูปแบบของทีมก็ได้

เริ่มจากตั้งชื่อ Diagram ให้ชัดว่ากำลังแสดงอะไรและมี Scope แค่ไหน เช่น Container View: Internet Banking System จากนั้นแต่ละกล่องควรมีมากกว่าชื่อ อาจระบุประเภทของ Element, Technology ที่สำคัญ และคำอธิบายสั้น ๆ ว่ามันรับผิดชอบอะไร เพื่อไม่ให้คนอ่านต้องเดาว่า Backend, Database หรือชื่อระบบภายในองค์กรทำหน้าที่อะไร

Press enter or click to view image in full size

ความสัมพันธ์ระหว่างกล่องก็มีความสำคัญไม่แพ้กัน ลูกศรควรมีทิศทางและข้อความที่อ่านเป็นประโยคได้ เช่น Web UI requests account information from Backend API ดีกว่าเขียนเพียง uses หรือปล่อยเส้นไว้โดยไม่มีคำอธิบาย หากมีทั้ง synchronous และ asynchronous communication อาจใช้เส้นคนละแบบได้ แต่ควรใช้ให้สม่ำเสมอ

สี, รูปร่าง, Icon หรือเส้นแบบพิเศษใช้เพิ่มความหมายได้ เช่น แยกระบบภายในกับระบบภายนอก หรือบอกส่วนที่กำลังเปลี่ยนใน Release นี้ แต่ทุกความหมายควรมี Legend กำกับเสมอ

หลักง่าย ๆ คือเลือก Notation ที่สม่ำเสมอ ลดความกำกวม และช่วยให้คนอ่านตอบได้ว่าแต่ละกล่องคืออะไร ทำอะไร และสัมพันธ์กับส่วนอื่นอย่างไร

Dynamic Diagram

C4 Model ระดับ Context, Container, Component และ Code ใช้อธิบายโครงสร้างแบบคงที่ของระบบ ว่ามีองค์ประกอบอะไรและเชื่อมต่อกันอย่างไร แต่ไม่ได้แสดงพฤติกรรมของระบบขณะทำงาน เช่น เมื่อผู้ใช้กดปุ่ม Sign in แล้ว Request Flow ทางผ่านส่วนใดบ้าง

Dynamic Diagram คือ Supporting Diagram สำหรับอธิบายพฤติกรรมขณะ Runtime ของ Feature เดียว โดยนำเฉพาะ People, Software Systems, Containers, Components หรือ Code Elements ที่เกี่ยวข้องกับ Feature นั้นมาเรียงตามลำดับการทำงาน

Intent

แสดงว่า Feature หนึ่งทำงานอย่างไรตั้งแต่ต้นจนจบ และแต่ละ Element สื่อสารหรือทำงานร่วมกันตามลำดับใด โดยตัดองค์ประกอบที่ไม่เกี่ยวข้องกับ Flow นั้นออก เพื่อให้เห็น Runtime interaction ได้ชัดเจนขึ้น

Dynamic Behavior

Dynamic Diagram สามารถใช้ Notation ได้หลายแบบ แต่รูปแบบที่พบได้บ่อยมี 2 แบบ

• Sequence Diagram วาง Participants จากซ้ายไปขวา และเรียงเหตุการณ์ตามเวลาจากบนลงล่าง เหมาะเมื่ออยากเห็นลำดับของ Interaction, Request และ Response อย่างชัดเจน
• Communication Diagram ใช้กล่องและลูกศรในลักษณะเดียวกับ Component Diagram แล้วกำกับหมายเลขบนความสัมพันธ์เพื่อบอกลำดับของ Interaction เหมาะสำหรับอธิบาย Flow แบบกระชับ หรือวาดร่วมกันบน Whiteboard

Example

ตัวอย่างนี้อธิบาย Flow ของการ Sign-in เมื่อผู้ใช้ส่ง Username และ Password ผ่าน Web UI ข้อมูลจะถูกส่งต่อไปยัง Sign-in API ซึ่งเรียก Security Component เพื่อตรวจสอบ Credentials กับ User Database เมื่อยืนยันตัวตนสำเร็จ ระบบจะสร้าง Authentication Token และส่งผลลัพธ์กลับไปยัง Web UI

Sequence Diagram

Sequence Diagram เรียง Participants จากซ้ายไปขวา และแสดงลำดับของ Interaction จากบนลงล่าง จึงช่วยให้เห็นอย่างชัดเจนว่า Request และ Response เดินทางผ่านส่วนใดบ้างตลอด Flow ของการ Sign-in

Press enter or click to view image in full size

Communication Diagram

Communication Diagram เล่า Flow เดียวกันผ่านกล่องและลูกศรที่แสดงความสัมพันธ์ระหว่าง Elements ในระบบ แล้วกำกับหมายเลขบนลูกศรเพื่อบอกลำดับของ Interaction แทนการใช้แกนเวลา

Press enter or click to view image in full size

ภาพจึงยังแสดงได้ว่า Web UI เรียก Sign-in API, API เรียก Security Component และ Security Component ตรวจสอบข้อมูลกับ User Database แต่ทำให้เห็นตำแหน่งและความสัมพันธ์ต่าง ๆ เหมาะกับการอธิบาย Flow แบบกระชับหรือวาดร่วมกันบน Whiteboard

When to use

ไม่จำเป็นต้องสร้าง Dynamic Diagram สำหรับทุก Feature เพราะยิ่งมีภาพมาก ภาระในการดูแลให้สอดคล้องกับระบบก็ยิ่งสูง หนังสือแนะนำให้ใช้เท่าที่จำเป็น โดยเหมาะกับ Interaction ที่ซับซ้อน น่าสนใจ หรือเกิดซ้ำจนทีมควรมีความเข้าใจร่วมกัน

ระดับของภาพขึ้นอยู่กับเรื่องที่ต้องการสื่อ หากต้องการอธิบายการทำงานระหว่าง Software Systems หรือ Containers ภาพจะเหมาะกับคนหลายกลุ่มมากกว่า แต่เมื่อซูมลงไปถึง Components หรือ Code จะเหมาะกับทีม Engineering ที่ต้อง Implement และดูแลส่วนดังกล่าวโดยตรง

Conclusion

C4 Model ไม่ได้มีเป้าหมายให้ทีมวาด Diagram ให้ครบทุกประเภท แต่ช่วยให้เราเลือกมุมมองที่เหมาะกับสิ่งที่ต้องการสื่อ เริ่มจากภาพกว้างเพื่อให้เห็นขอบเขตของระบบ แล้วค่อยซูมเข้าไปเมื่อรายละเอียดนั้นช่วยให้ทีมตัดสินใจหรือทำงานต่อได้

สำหรับหลายทีม System Context Diagram และ Container Diagram ก็เพียงพอสำหรับอธิบายว่าระบบมีไว้เพื่อใคร เชื่อมต่อกับอะไร และภายในมี Application หรือ Data Store ใดบ้าง Component, Code หรือ Dynamic Diagram ควรเพิ่มเมื่อมีคำถามเฉพาะที่ภาพระดับก่อนหน้ายังตอบไม่ได้

ไม่มี Diagram ใดอธิบายระบบได้ครบทุกมุม เราจึงควรเลือกใช้ Diagram ให้เหมาะกับคำถามและ Audience ที่ต้องการสื่อสาร ใครสนใจสามารถศึกษารายละเอียดเพิ่มเติมได้ที่ C4 Model guidance

อ้างอิง

• The C4 Model: Visualizing Software Architecture (O’Reilly)
• The C4 Model — Beyond The Basics • Simon Brown • YOW! 2025