Bốn tầng Context, Container, Component, Code cho bạn một bức tranh tĩnh của một hệ thống phần mềm duy nhất. Nhưng trong thế giới thực, hệ thống nào cũng có hàng xóm: nó gọi API của hệ thống khác, bị hệ thống khác gọi, chia sẻ database, phụ thuộc lẫn nhau chằng chịt. Nếu bạn quản lý cả một danh mục hệ thống trong công ty, chỉ vẽ từng hệ thống riêng lẻ là không đủ. Đó là lý do C4 có thêm 3 loại sơ đồ bổ trợ dưới đây.
Sơ đồ cảnh quan hệ thống (System Landscape diagram)
Nếu sơ đồ ngữ cảnh hệ thống (System Context, tầng đầu tiên trong 4 tầng chính) là bản vẽ của một tòa nhà, thì sơ đồ cảnh quan hệ thống giống bản quy hoạch của cả một khu đô thị: bạn không zoom vào chi tiết một tòa nhà nào, mà nhìn xem cả khu có bao nhiêu tòa nhà, chúng nằm cạnh nhau ra sao. Về mặt kỹ thuật, đây thực chất là sơ đồ ngữ cảnh hệ thống nhưng không tập trung vào riêng một hệ thống nào, mà vẽ toàn bộ các hệ thống phần mềm trong phạm vi bạn chọn (một doanh nghiệp, một tổ chức, hoặc một bộ phận), kèm theo mức chi tiết C4 đầy đủ cho những hệ thống bạn quan tâm nhất.
- Phạm vi: một doanh nghiệp, tổ chức, bộ phận, v.v.
- Yếu tố chính: con người và hệ thống phần mềm liên quan đến phạm vi đã chọn.
- Đối tượng mục tiêu: cả người có kiến thức kỹ thuật lẫn người không rành kỹ thuật, trong và ngoài nhóm phát triển phần mềm.
Dùng sơ đồ này khi bạn cần trả lời câu hỏi kiểu "công ty mình có bao nhiêu hệ thống, hệ thống nào nói chuyện với hệ thống nào" trước khi đi sâu vào từng hệ thống cụ thể.
Sơ đồ động (Dynamic diagram)
Bốn tầng Context, Container, Component, Code chỉ vẽ cấu trúc tĩnh: cái gì tồn tại và kết nối với cái gì. Chúng không nói rõ thứ tự các lời gọi diễn ra khi có một hành động cụ thể xảy ra. Sơ đồ động giải quyết đúng chỗ trống đó: nó cho thấy các phần tử trong mô hình tĩnh phối hợp với nhau như thế nào lúc chạy (runtime), để thực hiện một câu chuyện người dùng (user story), một trường hợp sử dụng (use case), hay một tính năng cụ thể.
Bạn có thể hình dung sơ đồ động giống storyboard của một cảnh phim: mỗi ô là một bước, được đánh số theo đúng thứ tự xảy ra, để người xem biết "ai gọi ai trước". Nó dựa trên sơ đồ giao tiếp UML (trước đây gọi là "UML collaboration diagram"), tương tự sơ đồ trình tự (sequence diagram) của UML, chỉ khác là các phần tử được sắp xếp tự do trên sơ đồ thay vì xếp thành cột thẳng hàng, và thứ tự tương tác được thể hiện bằng số đánh dấu.
- Phạm vi: một tính năng, một câu chuyện người dùng, một trường hợp sử dụng cụ thể, v.v.
- Yếu tố chính và hỗ trợ: tùy bạn chọn, có thể là hệ thống phần mềm, container, hoặc component đang tương tác lúc chạy.
- Đối tượng mục tiêu: cả người có kiến thức kỹ thuật lẫn người không rành kỹ thuật, trong và ngoài nhóm phát triển phần mềm.
Sơ đồ triển khai (Deployment diagram)
Sơ đồ triển khai trả lời câu hỏi: các phiên bản (instance) của hệ thống phần mềm và/hoặc container trong mô hình tĩnh của bạn thực sự đang chạy trên hạ tầng nào, ở môi trường triển khai nào (production, staging, dev, v.v.)? Nó dựa trên sơ đồ triển khai (deployment diagram) của UML.
Bạn có thể ví nó như bản vẽ mặt bằng của một căn nhà, chỉ rõ phòng nào đặt máy giặt, phòng nào đặt tủ lạnh, thay vì chỉ nói "nhà có máy giặt và tủ lạnh" như sơ đồ container. "Nút triển khai" (deployment node) trong sơ đồ này biểu thị nơi một phiên bản hệ thống/container đang chạy: có thể là hạ tầng vật lý (máy chủ, thiết bị vật lý), hạ tầng ảo hóa (IaaS, PaaS, máy ảo), hạ tầng đóng gói theo container (ví dụ Docker), hay môi trường thực thi (máy chủ cơ sở dữ liệu, máy chủ ứng dụng Java EE, Microsoft IIS, v.v.). Các nút triển khai có thể lồng vào nhau, ví dụ một máy ảo nằm trong một máy chủ vật lý.
Bạn cũng nên đưa vào các nút hạ tầng như dịch vụ DNS, bộ cân bằng tải (load balancer), tường lửa, v.v. nếu chúng đóng vai trò quan trọng trong việc vận hành.
- Phạm vi: một hoặc nhiều hệ thống phần mềm trong một môi trường triển khai duy nhất (production, staging, dev, v.v.).
- Thành phần chính: nút triển khai, phiên bản hệ thống phần mềm và phiên bản container.
- Yếu tố hỗ trợ: các nút hạ tầng phục vụ việc triển khai hệ thống phần mềm.
- Đối tượng mục tiêu: người có kiến thức kỹ thuật trong và ngoài nhóm phát triển phần mềm, bao gồm kiến trúc sư phần mềm, nhà phát triển, kiến trúc sư hạ tầng và nhân viên vận hành/hỗ trợ.
Cạm bẫy và lưu ý thực tế
Vài điều tôi thấy dễ vấp khi áp dụng 3 sơ đồ này:
- Vẽ landscape quá chi tiết: sơ đồ cảnh quan hệ thống chỉ nên dừng ở mức "hệ thống nào nói chuyện với hệ thống nào", đừng nhét thêm chi tiết công nghệ, API, giao thức vào đây, việc đó để dành cho sơ đồ container của từng hệ thống.
- Nhầm sơ đồ động với sequence diagram đầy đủ: sơ đồ động cố tình bỏ bớt độ chính xác của thứ tự thời gian (timing) để dễ đọc hơn, nếu bạn cần mô tả chính xác từng millisecond, hãy dùng sequence diagram chuẩn UML.
- Quên chú giải icon trong deployment diagram: icon AWS/Azure nhìn đẹp nhưng không phải ai đọc cũng nhận ra ngay, thiếu chú giải thì sơ đồ chỉ đẹp chứ không giúp ích được nhiều.
- Vẽ deployment diagram chung cho mọi môi trường: production, staging, dev thường khác nhau về cụm (cluster), cân bằng tải, sao chép dữ liệu, nên C4 khuyến nghị tách riêng một sơ đồ triển khai cho mỗi môi trường thay vì gộp chung.
Tóm tắt
- System Landscape: bản đồ toàn cảnh nhiều hệ thống phần mềm trong một tổ chức, dùng khi bạn cần nhìn bức tranh lớn trước khi soi vào một hệ thống.
- Dynamic diagram: luồng tương tác lúc chạy giữa các phần tử trong mô hình tĩnh, dùng khi bạn cần kể câu chuyện "ai gọi ai trước, theo thứ tự nào" cho một tính năng cụ thể.
- Deployment diagram: bản đồ hạ tầng, cho biết hệ thống/container của bạn đang chạy ở đâu, trên môi trường nào.
- Cả ba đều là sơ đồ tùy chọn, chỉ nên vẽ khi chúng thực sự mang lại giá trị, không cần vẽ đủ cho mọi dự án.
- Kai