Vì sao sơ đồ kiến trúc gây rối

Hãy tưởng tượng một buổi họp lên kế hoạch cho hệ thống mới. Ai đó cầm bút lông, vẽ vài cái hộp lên bảng trắng rồi nối chúng bằng mũi tên. Một hộp ghi "Server", một hộp ghi "DB", một hộp là tên một class, một hộp là "Người dùng", còn có hộp ghi tên một hãng cloud. Mũi tên chằng chịt, không cái nào có nhãn.

Mọi người gật gù. Nhưng nếu hỏi riêng từng người "mũi tên này nghĩa là gì?", bạn sẽ nhận được ba câu trả lời khác nhau: người bảo đó là một lời gọi API, người bảo đó là luồng dữ liệu, người lại hiểu là phụ thuộc lúc biên dịch. Tấm bảng trông như có sự đồng thuận, nhưng thực ra mỗi cái đầu đang giữ một bức tranh riêng.

Vì sao một sơ đồ "vẽ cho có" lại dễ gây hiểu lầm đến vậy? Thường vì ba căn bệnh sau:

• ▸Mũi tên mơ hồ: một mũi tên có thể là gọi API, luồng dữ liệu, hay phụ thuộc - không ghi rõ thì mỗi người đoán một kiểu.
• ▸Thiếu chú giải (legend): hộp vuông, hộp tròn, màu xanh, màu đỏ... mỗi thứ ngụ ý gì? Không có chú giải thì người đọc tự bịa luật.
• ▸Trộn nhiều mức trừu tượng: một hộp là cả một hệ thống, hộp ngay cạnh lại là một class - như tấm bản đồ vừa vẽ cả thế giới vừa vẽ một con hẻm.

Căn bệnh thứ ba là nặng nhất. Khi cả hệ thống và một mẩu code nhỏ cùng nằm trên một sơ đồ, người đọc không biết đang nhìn ở "độ cao" nào, nên không thể suy luận đúng về tổng thể.

Giả sử bạn vẽ ra một sơ đồ thật đẹp. Vấn đề tiếp theo: bạn sẽ trình bày nó cho ai? Mỗi phòng ban cần một mức chi tiết khác hẳn nhau:

• ▸Sếp kinh doanh / sales: chỉ cần biết "hệ thống làm gì, ai dùng, nối với dịch vụ nào" - không quan tâm database tên gì.
• ▸Quản lý dự án (PM): muốn thấy các khối lớn để chia việc và ước lượng - web, mobile, API, dữ liệu.
• ▸Lập trình viên: cần chi tiết bên trong một khối để biết viết code ở đâu.
• ▸Vận hành (ops): quan tâm cái gì chạy ở đâu, triển khai ra sao.

Một sơ đồ đủ chi tiết cho lập trình viên sẽ làm người kinh doanh mù mịt; một sơ đồ gọn cho sếp lại khiến lập trình viên thiếu thông tin. Cố vẽ một bức làm hài lòng tất cả thường thành bức không phục vụ tốt cho ai.

Đây chính là chỗ C4 Model bước vào. C4 do Simon Brown đề xuất, là một cách nhìn kiến trúc phần mềm như một bộ bản đồ ở nhiều mức zoom - y như Google Maps.

Trên Google Maps, bạn zoom ra để thấy cả đất nước, zoom vào nữa thấy thành phố, vào nữa thấy khu phố, rồi tới từng con đường. Mỗi mức là cùng một thực tại, chỉ khác độ chi tiết - và mỗi mức hữu ích cho một mục đích khác nhau. C4 áp đúng ý đó cho phần mềm, với bốn mức (chữ "C" là viết tắt của bốn cái tên):

Trông một mức C4 thế nào? Đây là sơ đồ Context của Mèo Đói (app đặt đồ ăn) - so với tấm bảng trắng hỗn loạn ở Bước 1: mỗi hộp ghi rõ loại, mỗi mũi tên có nhãn rõ hướng.

Lý thuyết đủ rồi - hãy tự zoom thử. Widget dưới đây có hai dự án khác nhau: Lớp Học Trực Tuyến (nền tảng học online) và Mèo Đói (app đặt đồ ăn). Bắt đầu ở mức Context, rồi bấm vào hộp có dấu 🔍 để zoom vào trong; bấm "Zoom ra" để lùi lại.

• ▸Cùng một hệ thống, ba mức chi tiết - giống zoom bản đồ, không phải ba hệ thống khác nhau.
• ▸Công nghệ (như PostgreSQL, React Native) chỉ xuất hiện từ mức Container trở vào, không nhồi vào mức Context.
• ▸Người dùng (những chú mèo) đứng quanh rìa; mọi mũi tên đều có nhãn nêu rõ ai làm gì với ai.
• ▸Thử cả hai dự án: tư duy zoom giống hệt nhau, dù một bên là học online, một bên là giao đồ ăn.

So với tấm bảng trắng hỗn loạn ở Bước 1, C4 chữa cả ba căn bệnh bằng vài quy ước đơn giản:

• ▸Mỗi sơ đồ chỉ ở MỘT mức zoom - hết bệnh "trộn mức trừu tượng".
• ▸Ít kiểu hộp, mỗi hộp ghi rõ là người / hệ thống / container / component - đỡ cần chú giải rườm rà.
• ▸Mọi mũi tên đều có nhãn nêu rõ hướng và ý nghĩa - hết bệnh "mũi tên mơ hồ".
• ▸Chọn mức theo khán giả - nên không còn cảnh một sơ đồ làm khổ mọi phòng ban.

Khoá này sẽ đi từ nền tảng tới thực hành trên nhiều dự án. Bước kế tiếp là phân biệt cho rõ hai thứ người ta hay lẫn: mô hình so với sơ đồ và bốn khái niệm nền. Sau đó ta sẽ học kỹ từng mức, bắt đầu với Level 1: System Context.