# Tại sao developer vẽ diagram trông như... mớ hỗn độn?

Nếu bạn nhờ một kiến trúc sư xây dựng mô tả tòa nhà, họ sẽ đưa cho bạn bản vẽ mặt bằng, mặt đứng, mặt cắt — rõ ràng, có chuẩn, ai cũng hiểu. Còn nếu bạn nhờ một software developer vẽ kiến trúc hệ thống? Khả năng cao bạn sẽ nhận được... một mớ hộp và đường thẳng không biết đọc từ đâu.

Simon Brown — tác giả của C4 Model — đã chạy workshop với hàng nghìn developer trên toàn thế giới và nhận ra: khả năng giao tiếp trực quan về kiến trúc phần mềm đang bị mất dần. Đây là vấn đề nghiêm trọng hơn nhiều người nghĩ.

![](https://cdn.hashnode.com/uploads/covers/6a1c1e0799cfcad53bb29ec4/bc190f99-b5ee-48cf-84c9-f5950358ac17.png align="center")

## 1\. Chuyện gì đã xảy ra? - Agile tốt, nhưng chúng ta đã "vứt cả em bé theo chậu nước"

Khi Agile và Lean lên ngôi, nhiều team đã loại bỏ không chỉ các quy trình nặng nề như RUP hay SSADM — mà vứt luôn cả tài liệu và modelling theo. UML bị xem là "đồ cổ". Thay vào đó là những buổi whiteboard session với những diagram tự phát, không có chuẩn, không có ngữ nghĩa nhất quán.

Ngành phần mềm thiếu một bộ từ vựng chung. "Component", "module", "service" — ba từ này có thể chỉ cùng một thứ hoặc ba thứ hoàn toàn khác nhau, tùy người vẽ.

## 2\. Bộ sưu tập diagram "kinh điển"

Simon Brown đã thu thập từ các workshop — đây là những "tác phẩm" phổ biến nhất, và lý do chúng gây rối:

1.  **Thiếu context**  
    Diagram xuất hiện mà không có tiêu đề, phạm vi, hoặc mục đích. Người đọc không biết đây là tổng quan toàn hệ thống, luồng dữ liệu, hay diagram cho một feature cụ thể.
    
2.  **Danh sách công nghệ**  
    Liệt kê JBoss, SQL Server... nhưng không biết chúng làm gì hay kết nối thế nào — chỉ liệt kê để “khoe” công nghệ chứ không truyền đạt cấu trúc.
    
3.  **Thiếu quan hệ — hộp không có đường**  
    Có đủ các tầng, các component — nhưng không có mũi tên nào. Ai kết nối với ai? Dữ liệu chạy từ đâu tới đâu?
    
4.  **Không phân cấp/độ trừu tượng**  
    Trộn lẫn chi tiết cài đặt (class, table) với kiến trúc cấp cao (domain, subsystem) trong cùng một diagram khiến thông tin bị loãng và khó hiểu.
    
5.  **Ký hiệu và ngữ nghĩa không nhất quán**  
    Cùng một dạng hộp được dùng để biểu diễn service, database, và thậm chí team — người xem không thể suy ra ý nghĩa.
    
6.  **Quá chi tiết hoặc quá tóm tắt**  
    Một số diagram chứa mọi chi tiết nhỏ khiến người đọc bị ngợp; số khác chỉ có hai hộp và một mũi tên, không đủ thông tin để ra quyết định.
    
7.  **Text dài trong diagram**  
    Thay vì biểu diễn quan hệ bằng mũi tên và nhãn ngắn, nhiều diagram chứa đoạn văn dài, làm mất tính trực quan.
    

**Không được cập nhật**  
Diagram tồn tại nhưng không phản ánh thực tế hiện tại — điều này còn gây hại hơn là không có diagram.

![](https://cdn.hashnode.com/uploads/covers/6a1c1e0799cfcad53bb29ec4/94ab6b5f-5c06-408e-a0cd-5dd12a612aaf.png align="center")

## 3\. Hậu quả

*   Hiểu nhầm giữa các team (Dev, Prod, QA, Ops, BD...).
    
*   Quyết định kiến trúc dựa trên thông tin sai hoặc không đầy đủ.
    
*   Chi phí onboarding tăng, refactor và bug do thiếu rõ ràng về ranh giới trách nhiệm.
    

## 4\. Một số cách khắc phục (thực dụng)

*   Xác định mục đích cho mỗi diagram: Context? Container? Component? Sequence?
    
*   Áp dụng nguyên tắc phân tầng (ví dụ C4 — Context, Container, Component, Code): mỗi tầng có mục đích và mức trừu tượng khác nhau.
    
*   Đặt legend và conventions: những ký hiệu, màu, kiểu đường phải có giải thích ngắn gọn.
    
*   Giữ diagram đơn giản, chỉ biểu diễn điều cần thiết cho mục đích đó.
    
*   Viết chú thích ngắn, xác định phạm vi và ngày cập nhật.
    
*   Làm diagrams thành living artifacts: tích hợp vào CI/CD, lưu ở nơi dễ tiếp cận, cập nhật khi thay đổi.
    
*   Dùng tooling phù hợp: draw.io, PlantUML, Structurizr, hay các công cụ hỗ trợ versioning để dễ duy trì.
    
*   Thỏa thuận ngôn ngữ chung trong team cho "component/module/service" để tránh nhầm lẫn.
    

## 5\. Checklist nhanh trước khi share diagram

*   Mục đích của diagram là gì? (1 câu)
    
*   Phạm vi là gì? (phần hệ thống nào)
    
*   Ai là khán giả chính? (Dev, QA, Manager, khách hàng)
    
*   Có legend và ngày cập nhật không?
    
*   Diagram có phản ánh state hiện tại không?
    
*   Có thể hiểu được trong 30–60s không?
    

Kết luận: vẽ diagram không phải chỉ để “điền” vào báo cáo hay khoe tech stack — nó là công cụ giao tiếp. Nếu dùng đúng cách (mục đích rõ ràng, mức trừu tượng phù hợp, ký hiệu nhất quán, và được duy trì), diagram sẽ giúp team ra quyết định nhanh hơn, giảm sai sót và truyền đạt kiến trúc hiệu quả hơn.

## **6\. Tài liệu tham khảo**

*   Simon Brown — *The C4 Model for Visualising Software Architectur*