de_DEen_USes_ESfa_IRfr_FRhi_INid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

Khám phá sâu cấp độ 3 Mô hình C4: Thành thạo sơ đồ thành phần để tiết lộ cấu trúc bên trong và trách nhiệm

Sơ đồ thành phần C4 là gì?

Sơ đồ thành phần làCấp độ 3trong mô hình C4 của Simon Brown. Nó phóng to vàomột container cụ thể (từ sơ đồ Container cấp độ 2) để hiển thị:

The Ultimate Guide to C4 Model Visualization with Visual Paradigm's AI Tools - ArchiMetric

  • Nhữngkhối xây dựng logic (thành phần) tạo nên container đó.

  • Cách các thành phần đótương tácvới nhau.

  • Trách nhiệmvàcác công nghệ triển khai (ở cấp độ cao hơn lớp — hãy nghĩ đến Spring Beans, module, dịch vụ, controller, facade, v.v.).

  • Cácgiao diệnhoặchợp đồnggiữa các thành phần (thường ngầm hiểu qua các mối quan hệ).

Lưu ý quan trọng: Một “thành phần” trong C4 làkhông phảimột lớp. Nó làsự nhóm logic các lớpnằm sau một giao diện được xác định rõ — thứ gì đó có trách nhiệm rõ ràng, có thể được phát triển/thử nghiệm/triển khai tương đối độc lập (trong phạm vi container), nhưng làkhông phảiđược triển khai riêng biệt như một container.

Ví dụ về các thành phần:

  • Controller REST / Controller Web

  • Dịch vụ / Trường hợp sử dụng / Dịch vụ Ứng dụng

  • Kho lưu trữ / Đối tượng truy cập dữ liệu

  • Mô hình miền / Thực thể

  • Bảo mật / Module xác thực

  • Bộ gửi thông báo

  • Lớp mặt trước cho hệ thống bên ngoài

  • Động cơ quy tắc kinh doanh

  • Lớp bộ nhớ đệm

Sơ đồ vẫn giữ nguyên hợp lý / đủ trừu tượng về mặt triển khai — không có thuộc tính lớp, chữ ký phương thức, hay chi tiết lớp UML đầy đủ (đó là Mã cấp 4, tùy chọn và hiếm gặp).

Khi nào nên tạo sơ đồ thành phần

Tạo (và duy trì) sơ đồ thành phần chỉ khi:

  • Container được chọn là phức tạp đủ mức đến mức cấu trúc bên trong không rõ ràng chỉ từ tên và mô tả của nó.

  • Các thành viên mới trong nhóm (đặc biệt là các nhà phát triển backend) thường xuyên hỏi: “Tính năng X thực sự được triển khai như thế nào bên trong dịch vụ/API này?”

  • Bạn đang tái cấu trúc, chia nhỏ, hoặc trích xuất logic bên trong một container và cần làm rõ ranh giới/trách nhiệm.

  • Bạn đang thực hiện chi tiết các thảo luận thiết kế, xem xét mã nguồn, hoặc chuyển giao nhiệm vụ trực ca cho một container cụ thể.

  • Bạn muốn tài liệu hóa các quyết định kiến trúc cốt lõi bên trong một container (ví dụ: kiến trúc hình lục giác, phân mảnh theo chiều dọc, tách biệt CQRS, điểm thực thi bảo mật).

  • Bạn đã xác định được nợ kỹ thuật, lớp thần, hoặc kết nối chặt chẽ bên trong một container và muốn trực quan hóa tình trạng hiện tại trước khi dọn dẹp.

  • Bạn đang đưa các nhà phát triển/nhà kiến trúc cấp cao mới vào làm việc, những người cần hiểu cấu trúc module một cách nhanh chóng.

Không được tạo sơ đồ thành phần cho:

  • Các container đơn giản (API CRUD với một controller + một service + một repository — cấu trúc rõ ràng).

  • Hầu hết các microservice (thường nhỏ đến mức mức container là đủ).

  • Các container phía trước (ứng dụng React/Vue — thường tốt hơn khi thể hiện bằng cây thành phần hoặc storybook).

  • Khi mức 2 (container) + cấu trúc mã nguồn tốt/tên gọi hợp lý đã truyền đạt đầy đủ mọi thứ cần thiết.

Simon Brown khuyến nghị: Hầu hết các đội có thể dừng lại ở mức 1 + 2. Chỉ đi đến mức 3 đối với các phức tạp / rủi ro / cốt lõi / thay đổi thường xuyên container.

Tại sao nên sử dụng sơ đồ thành phần? (Lợi ích chính)

  • Làm rõ trách nhiệm nội bộ — Thể hiện sự tách biệt trách nhiệm (ví dụ: controller so với service so với truy cập dữ liệu so với tích hợp bên ngoài).

  • Bộc lộ sự kết nối và phụ thuộc — Làm rõ các thành phần thần thánh, các phụ thuộc vòng lặp, hoặc sự phụ thuộc quá mức vào mã nguồn cơ sở hạ tầng.

  • Hỗ trợ quá trình giới thiệu và chuyển giao tốt hơn — Các nhà phát triển hiểu rõ ranh giới module nhanh hơn so với việc đọc tất cả các tệp nguồn.

  • Hướng dẫn việc tái cấu trúc và phát triển — Cơ sở hình ảnh trực quan trước/sau khi tách monolith hoặc giới thiệu các mẫu (cổng và bộ chuyển đổi, các mảng dọc).

  • Cho phép đánh giá kiến trúc và mô hình hóa mối đe dọa — Xác định rõ nơi diễn ra kiểm tra tính hợp lệ, xác thực, ghi nhật ký, v.v.

  • Kiến trúc dưới dạng mã nguồn — Khi được lưu trong PlantUML → được quản lý phiên bản cùng với mã nguồn, so sánh được, có thể xem xét trong các yêu cầu hợp nhất (PR).

  • Mở rộng khả năng giao tiếp — Các lập trình viên cấp cao quan tâm đến trách nhiệm của thành phần; các lập trình viên mới quan tâm đến nơi đặt mã nguồn mới.

Làm thế nào để tạo một sơ đồ thành phần tuyệt vời (Bước từng bước + Các thực hành tốt nhất)

  1. Chọn MỘT container — Bắt đầu với container phức tạp nhất hoặc quan trọng nhất về mặt kinh doanh (thường là API chính / dịch vụ backend).

  2. Sao chép bối cảnh từ cấp độ 2 — Bao gồm các tác nhân bên ngoài (các container khác, con người, hệ thống bên ngoài) tương tác với container này.

  3. Vẽ ranh giới container — Sử dụng Ranh_giới_container trong PlantUML để rõ ràng xác định phạm vi “bên trong container này”.

  4. Xác định các thành phần — Hỏi:

    • Các module chính / Spring Beans / gói / bối cảnh giới hạn bên trong là gì?

    • Yêu cầu đầu vào được xử lý ở đâu? (controller/handler)

    • Nơi nào được điều phối logic kinh doanh?

    • Nơi nào dữ liệu được truy cập / đệm / xác thực?

    • Nơi nào xử lý các vấn đề xuyên suốt? (bảo mật, ghi nhật ký)

    • Có các lớp mặt trước / lớp chống suy thoái nào cho hệ thống cũ/hệ thống bên ngoài không?

  5. Thêm công nghệ và mô tả ngắn gọn — Tên, công nghệ (Spring Service, .NET Handler, Go Module, v.v.), mục đích ngắn gọn (< 15 từ).

  6. Xác định tương tác — Hiển thị hướng đi + mục đích (Sử dụng, Gọi, Đọc từ, Phát sự kiện đến). Giao thức thường được bỏ qua ở cấp độ này.

  7. Thực hành tốt nhất

    • Hạn chế phạm vi — Tối đa 6–12 thành phần trên mỗi sơ đồ. Nếu nhiều hơn → tạo các bản xem tập trung (ví dụ: “mảnh Xác thực”).

    • Đặt tên có ý nghĩa — Ưu tiên “Dịch vụ Đặt hàng” thay vì “OrderService”.

    • Hiển thị trách nhiệm, không phải lớp — Tránh liệt kê từng lớp; nhóm một cách hợp lý.

    • Sử dụng biểu tượng một cách tiết chế — Chỉ khi chúng làm rõ công nghệ (biểu tượng Spring, .NET).

    • Bật chú giải — Giúp người đọc mới dễ hiểu.

    • Giữ bố cục sạch sẽ — BỐ CỤC_CÓ_CHÚ GIẢI(), BỐ CỤC_TỪ_TRÊN_XUỐNG_DƯỚI().

    • Phiên bản trong kho lưu trữ — Các tệp .puml nằm cạnh mã nguồn của container.

    • Lặp lại — Cập nhật trong các đợt tái cấu trúc hoặc kiểm tra sức khỏe kiến trúc định kỳ.

Ví dụ PlantUML – Ứng dụng API Hệ thống Ngân hàng Trực tuyến (phong cách Big Bank plc cổ điển)

Dưới đây là một ví dụ cấp sản phẩm sử dụng thư viện C4-PlantUML chính thức — mẫu thực tế được tham khảo phổ biến nhất.

@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Component.puml

title Sơ đồ Thành phần: Hệ thống Ngân hàng Trực tuyến - Ứng dụng API

' Người dùng / các thành phần bên ngoài từ cấp Container
Container(spa, "Ứng dụng Trang Đơn", "JavaScript & Angular", "Cung cấp giao diện người dùng ngân hàng trực tuyến qua trình duyệt")
Container(mobile, "Ứng dụng Di động", "iOS/Android", "Cung cấp chức năng ngân hàng di động hạn chế")
ContainerDb(database, "Cơ sở dữ liệu Ngân hàng", "PostgreSQL", "Lưu trữ tùy chọn người dùng, dữ liệu đã cache, phiên đăng nhập")
System_Ext(mainframe, "Hệ thống Ngân hàng Chính", "Mainframe – tài khoản và giao dịch chính")

' Container mà chúng ta đang phóng to
Container_Boundary(api, "Ứng dụng API") {
    Component(signInCtrl, "Controller Đăng nhập", "Spring MVC REST Controller", "Xử lý xác thực và tạo phiên đăng nhập")
    Component(accountsCtrl, "Controller Tóm tắt Tài khoản", "Spring MVC REST Controller", "Cung cấp số dư và tóm tắt tài khoản")
    Component(resetPwdCtrl, "Controller Đặt lại Mật khẩu", "Spring MVC REST Controller", "Quản lý luồng đặt lại mật khẩu")
    
    Component(security, "Thành phần Bảo mật", "Spring Bean", "Token JWT, băm mật khẩu, kiểm tra vai trò")
    Component(accountService, "Thành phần Quản lý Tài khoản", "Spring Bean / Dịch vụ", "Điều phối truy vấn tài khoản và quy tắc kinh doanh")
    Component(mainframeFacade, "Bộ phận Giao diện Ngân hàng Mainframe", "Spring Bean", "Lớp chống ô nhiễm từ mainframe cũ")
    Component(emailNotifier, "Thành phần Thông báo Email", "Spring Bean", "Gửi email xác nhận và đặt lại mật khẩu")
}

' Mối quan hệ bên trong ranh giới
Rel(signInCtrl, security, "Sử dụng")
Rel(accountsCtrl, accountService, "Sử dụng")
Rel(resetPwdCtrl, security, "Sử dụng")
Rel(resetPwdCtrl, emailNotifier, "Sử dụng")
Rel(accountService, mainframeFacade, "Sử dụng")
Rel(accountService, database, "Đọc từ và ghi vào", "JDBC")
Rel(mainframeFacade, mainframe, "Sử dụng", "XML/HTTPS")
Rel(emailNotifier, database, "Đọc tùy chọn người dùng", "JDBC")

' Gọi đến từ phía trước
Rel(spa, signInCtrl, "Sử dụng", "JSON/HTTPS")
Rel(spa, accountsCtrl, "Sử dụng", "JSON/HTTPS")
Rel(spa, resetPwdCtrl, "Sử dụng", "JSON/HTTPS")
Rel(mobile, signInCtrl, "Sử dụng", "JSON/HTTPS")
Rel(mobile, accountsCtrl, "Sử dụng", "JSON/HTTPS")
Rel(mobile, resetPwdCtrl, "Sử dụng", "JSON/HTTPS")

BỐ CỤC_CÓ_CHÚ GIẢI()
BỐ CỤC_TRÁI_PHẢI()

@enduml

Điều này tạo ra:

  • Ranh giới rõ ràng xung quanh container API

  • Sắp xếp hợp lý các controller, dịch vụ, bộ giao diện

  • Trách nhiệm chính xác

  • Tương tác chính và phụ thuộc

  • Chú thích tự động để dễ đọc

Dán vào trình render PlantUML (trực tuyến hoặc IDE) — tùy chỉnh tên/công nghệ cho hệ thống của bạn.

Sử dụng mẫu này như mẫu khởi đầu. Mục tiêu luôn là giao tiếp hiệu quả giữa các đội nhóm — chứ không phải vẻ đẹp của sơ đồ. Chúc bạn thiết kế vui vẻ!

Tài nguyên Sơ đồ Thành phần C4

This post is also available in Deutsch, English, Español, فارسی, Français, English, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, 简体中文 and 繁體中文.