Mô hình C4 là gì? Cách vẽ sơ đồ kiến trúc phần mềm dễ hiểu
Mô hình C4 là phương pháp trực quan hóa kiến trúc phần mềm bằng 4 cấp độ trừu tượng: Context, Containers, Components và Code. Do Simon Brown phát triển, C4 giúp các nhóm kỹ thuật và phi kỹ thuật cùng hiểu một hình ảnh chung về hệ thống.
Thay vì dùng UML phức tạp, C4 tập trung vào sơ đồ đơn giản, thực tế, có thể vẽ bằng tay hoặc công cụ như Structurizr, Mermaid, PlantUML. Mỗi cấp độ trả lời một câu hỏi: hệ thống giải quyết vấn đề gì? Các container là gì? Các component bên trong container? Code triển khai như thế nào?
Bốn cấp độ trừu tượng của C4
1. System Context (Bối cảnh hệ thống) – Sơ đồ cấp cao nhất, hiển thị hệ thống như một hộp đen, người dùng, hệ thống bên ngoài và luồng dữ liệu giữa chúng. Dành cho business stakeholder, product manager.
2. Container Diagram (Sơ đồ container) – Mở hộp hệ thống thành các container: ứng dụng web, mobile app, database, message queue, microservice, v.v. Mỗi container là đơn vị triển khai có thể chạy độc lập. Dành cho developer, devops, tester.
3. Component Diagram (Sơ đồ thành phần) – Phân tách một container thành các component logic: controller, service, repository, event handler. Dành cho nhóm phát triển chính, code reviewer.
4. Code Diagram (Sơ đồ mã nguồn) – Cấp chi tiết nhất, thể hiện class, interface, function. Thường không vẽ tay mà sinh tự động từ code (Java, C#, TypeScript). Dành cho người bảo trì code.
Ký hiệu và quy tắc vẽ C4
- Hình chữ nhật: container, component, external system.
- Mũi tên: quan hệ sử dụng (uses), luồng dữ liệu, gọi API.
- Màu sắc: nhóm theo công nghệ (Java, Go, PostgreSQL, Kafka).
- Chú thích: mô tả công nghệ, giao thức, tiêu chuẩn.
Không bắt buộc vẽ đủ 4 cấp. Hầu hết nhóm chỉ cần Context + Container để truyền thông hiệu quả. Component bổ sung khi refactor lớn hoặc onboarding developer mới.
So sánh với các phương pháp khác
So với UML component diagram, C4 nhẹ hơn, ít ký hiệu, tập trung vào yếu tố triển khai (container) chứ không chỉ logic. So với sơ đồ 4+1 view (Kruchten), C4 không tách view logic/implementation/process/deployment – nó xếp chồng các view đó vào 4 cấp độ đơn giản.
C4 cũng tương thích với ADR (Architecture Decision Record): mỗi quyết định kiến trúc có thể tham chiếu sơ đồ C4 cụ thể để chứng minh lý do.
Công cụ hỗ trợ vẽ C4
- Structurizr: công cụ chuyên dụng của tác giả, có DSL và web viewer.
- Mermaid / PlantUML: vẽ trong Markdown, tích hợp Git, CI/CD.
- draw.io, Lucidchart: kéo thả, phù hợp workshop nhanh.
Ví dụ thực tế: Hệ thống đặt vé xem phim
Context: người dùng web và người dùng ứng dụng di động là hai tác nhân khác nhau, dùng chung một hệ thống. Bên ngoài còn có cổng thanh toán và hệ thống quản lý rạp chiếu. Sơ đồ Context ở mức này chỉ có ba hộp và vài mũi tên, đọc trong vòng một phút.
Container: Web App chạy React, Mobile App chạy Flutter, API Gateway chạy Spring Boot để kiểm tra xác thực và định tuyến yêu cầu, ba dịch vụ nghiệp vụ tách theo miền (User, Movie, Booking), một cơ sở dữ liệu PostgreSQL và một message broker Kafka cho các sự kiện bất đồng bộ như gửi email xác nhận.
Component trong Service Booking: BookingController tiếp nhận yêu cầu, BookingService chứa logic kiểm tra ghế, SeatRepository truy vấn cơ sở dữ liệu, PaymentClient gọi cổng thanh toán, NotificationEvent phát sự kiện sang Kafka. Sơ đồ Component chỉ nên vẽ khi đang sửa một trong các phần này, không cần vẽ cho cả ba dịch vụ cùng lúc.
Deployment: sơ đồ triển khai cho biết các container đặt ở đâu – Web App và Mobile App chạy trên dịch vụ hosting tĩnh và CDN, API Gateway chạy trên cụm Kubernetes phía sau, cơ sở dữ liệu nằm trong vùng mạng riêng chỉ cho phép kết nối từ các dịch vụ nội bộ. Đây là sơ đồ giúp đội vận hành kiểm tra xem cổng mở có đúng hay không.
C4 model và vòng đời phát triển phần mềm
Một ưu điểm ít được nói đến của C4 là khả năng dùng như công cụ trong vòng đời phát triển. Sơ đồ Context thường được cập nhật khi trao đổi với khách hàng hoặc quản lý sản phẩm; sơ đồ Container cập nhật mỗi khi thêm dịch vụ mới; sơ đồ Component thay đổi khi tái cấu trúc mô-đun. Nhờ vậy tài liệu kiến trúc không bị bỏ quên như một bản vẽ đẹp nhưng lỗi thời.
Nhiều nhóm kỹ thuật kết hợp C4 với tài liệu quyết định kiến trúc. Mỗi quyết định được ghi lại cùng lý do, các phương án đã cân nhắc và phần sơ đồ C4 minh hoạ tác động. Khi có tranh chấp về thiết kế sau này, nhóm có tài liệu để tra lại thay vì tranh luận từ trí nhớ.
Cần lưu ý một điểm về tên gọi: từ “container” trong C4 không có nghĩa container hóa như Docker hay Kubernetes. Một container trong C4 chỉ là một đơn vị ứng dụng có thể chạy riêng, chẳng hạn một ứng dụng web, một cơ sở dữ liệu, hay một worker xử lý nền. Nếu nhóm vừa dùng cả hai khái niệm, nên chú thích rõ ngay trên sơ đồ để tránh nhầm lẫn khi trao đổi.
Quy trình vẽ C4 trong thực tế
- Bắt đầu từ danh sách người dùng và hệ thống bên ngoài mà hệ thống phải trao đổi. Đây là nội dung sơ đồ Context.
- Tách hệ thống thành các container theo ranh giới triển khai thực tế, không theo cấu trúc thư mục mã nguồn.
- Chỉ vẽ sơ đồ Component cho container đang được sửa đổi nhiều hoặc gây nhiều lỗi, để tiết kiệm thời gian cập nhật.
- Đưa sơ đồ vào kho mã nguồn cùng tài liệu, để mỗi thay đổi kiến trúc đều được xem xét khi duyệt mã.
Kết luận
Mô hình C4 biến kiến trúc từ tài liệu khô khan thành ngôn ngữ chung của cả nhóm. Việc bắt đầu bằng Context diagram rồi dần sâu vào Container, Component giúp mọi người nắm bắt bức tranh toàn cảnh trước khi đi vào chi tiết.
Nguồn tham khảo: Wikipedia – C4 model, c4model.com – Trang chủ chính thức.
