de_DEen_USes_ESfa_IRfr_FRhi_INid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

Penyelidikan Mendalam Level 3 Model C4: Menguasai Diagram Komponen untuk Mengungkap Struktur Internal dan Tanggung Jawab

Apa itu Diagram Komponen C4?

Diagram Komponen adalahLevel 3 dalam model C4 Simon Brown. Ini memperbesar satu wadah tertentu (dari diagram Wadah Level 2) untuk menunjukkan:

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

  • The blok bangunan logis (komponen) yang membentuk wadah tersebut.

  • Bagaimana komponen-komponen tersebut berinteraksi satu sama lain.

  • Tanggung jawab dan teknologi implementasi (pada tingkat yang lebih tinggi daripada kelas — pikirkan Spring Beans, modul, layanan, kontroler, fasad, dll.).

  • Kunci antarmuka atau kontrak antara komponen (sering tersirat melalui hubungan).

Penjelasan penting: Sebuah “komponen” dalam C4 adalah bukan kelas. Ini adalah pengelompokan logis kelas-kelas di balik antarmuka yang jelas — sesuatu yang memiliki tanggung jawab yang jelas, dapat dikembangkan/uji/deploy secara sebagian independen (dalam wadah), tetapi tidak bukan dapat di-deploy secara terpisah seperti wadah.

Contoh komponen:

  • REST Controller / Web Controller

  • Layanan / Use Case / Layanan Aplikasi

  • Repository / Objek Akses Data

  • Model Domain / Entitas

  • Keamanan / Modul Autentikasi

  • Pengirim Notifikasi

  • Facade ke sistem eksternal

  • Mesin Aturan Bisnis

  • Lapisan Penyimpanan Sementara

Diagram tetap logis / cukup bebas dari implementasi — tidak ada atribut kelas, tanda tangan metode, atau detail kelas UML lengkap (itu adalah Kode Tingkat 4, yang opsional dan langka).

Kapan Membuat Diagram Komponen

Buat (dan pertahankan) diagram komponen hanya ketika:

  • Wadah yang dipilih adalah cukup kompleks sehingga struktur internalnya tidak jelas hanya dari namanya dan deskripsinya saja.

  • Anggota tim baru (terutama pengembang backend) sering bertanya: “Bagaimana fitur X sebenarnya diimplementasikan di dalam layanan/API ini?”

  • Anda sedang refactoring, membelah, atau mengekstrak logika di dalam wadah dan perlu menjelaskan batas/tanggung jawab.

  • Anda sedang melakukan pembahasan rinci diskusi desain, tinjauan kode, atau serah terima tugas on-call untuk kontainer tertentu.

  • Anda ingin mendokumentasikan keputusan arsitektur utama di dalam kontainer (misalnya, arsitektur heksagonal, potongan vertikal, pemisahan CQRS, titik penegakan keamanan).

  • Anda telah mengidentifikasi utang teknis, kelas dewa, atau keterikatan erat di dalam kontainer dan ingin memvisualisasikan kondisi saat ini sebelum pembersihan.

  • Anda sedang melakukan onboarding developer/architect senior yang perlu memahami struktur modul dengan cepat.

Jangan membuat diagram komponen untuk:

  • Kontainer sederhana (API CRUD dengan satu controller + satu service + satu repository — struktur yang jelas).

  • Sebagian besar mikroservis (seringkali cukup kecil sehingga tingkat kontainer sudah cukup).

  • Kontainer front-end (aplikasi React/Vue — biasanya lebih baik ditampilkan dengan pohon komponen atau storybook).

  • Ketika Tingkat 2 (Kontainer) + struktur kode/nama yang baik sudah menyampaikan semua yang dibutuhkan.

Simon Brown menyarankan: Sebagian besar tim dapat berhenti di Tingkat 1 + 2. Hanya lanjut ke Tingkat 3 untuk rumit / berisiko / inti / tingkat pergantian tinggi kontainer.

Mengapa Menggunakan Diagram Komponen? (Manfaat Utama)

  • Mengklarifikasi tanggung jawab internal — Menunjukkan pemisahan tanggung jawab (misalnya, controller vs service vs akses data vs integrasi eksternal).

  • Mengungkap keterikatan dan ketergantungan — Menampilkan komponen tuhan, ketergantungan siklik, atau ketergantungan berlebihan pada kode infrastruktur.

  • Mendukung onboarding & serah terima yang lebih baik — Pengembang memahami batas modul lebih cepat daripada membaca semua file sumber.

  • Membimbing refactoring & evolusi — Dasar visual sebelum/sesudah membagi monolit atau memperkenalkan pola (port dan adapter, potongan vertikal).

  • Memungkinkan ulasan arsitektur & pemodelan ancaman — Menunjukkan di mana validasi, otorisasi, pencatatan log, dll., terjadi.

  • Arsitektur sebagai kode — Saat disimpan dalam PlantUML → dikelola versi bersama kode, dapat dibandingkan, dapat ditinjau dalam PR.

  • Meningkatkan komunikasi — Developer senior peduli tanggung jawab komponen; junior peduli di mana menempatkan kode baru.

Cara Membuat Diagram Komponen yang Hebat (Langkah demi Langkah + Praktik Terbaik)

  1. Pilih SATU kontainer — Mulai dengan yang paling kompleks atau kritis secara bisnis (seringkali API utama / layanan backend).

  2. Salin konteks dari Level 2 — Sertakan aktor eksternal (kontainer lain, orang, sistem eksternal) yang berinteraksi dengan kontainer ini.

  3. Gambar batas kontainer — Gunakan Batasan_Kontainer di PlantUML untuk dengan jelas menentukan ‘di dalam kontainer ini’.

  4. Identifikasi Komponen — Tanyakan:

    • Apa modul utama / Spring Beans / paket / konteks terbatas yang ada di dalamnya?

    • Di mana permintaan masuk mendarat? (controller/handler)

    • Di mana logika bisnis diatur?

    • Di mana data diakses / disimpan sementara / divalidasi?

    • Di mana masalah lintas komponen ditangani? (keamanan, pencatatan log)

    • Ada fasad / lapisan anti-korupsi ke sistem warisan/eksternal?

  5. Tambahkan Teknologi & Deskripsi Singkat — Nama, teknologi (Spring Service, .NET Handler, Modul Go, dll.), tujuan singkat (< 15 kata).

  6. Tentukan Interaksi — Tunjukkan arah + niat (Menggunakan, Memanggil, Membaca dari, Mengirimkan peristiwa ke). Protokol sering diabaikan pada tingkat ini.

  7. Praktik Terbaik

    • Batasi cakupan — Maksimal 6–12 komponen per diagram. Jika lebih → buat tampilan sub fokus (misalnya, “potongan Autentikasi”).

    • Berikan nama yang bermakna — Lebih baik gunakan “Layanan Penempatan Pesanan” daripada “OrderService”.

    • Tampilkan tanggung jawab, bukan kelas — Hindari mencantumkan setiap kelas; kelompokkan secara logis.

    • Gunakan ikon secara hemat — Hanya jika mereka membantu menjelaskan teknologi (ikon Spring, .NET).

    • Aktifkan legenda — Membantu pembaca baru.

    • Jaga tata letak tetap bersih — TATALETAK_DENGAN_LEGENDA(), TATALETAK_ATAS_BAWAH().

    • Versi di repositori — File .puml bersebelahan dengan kode container.

    • Iterasi — Perbarui saat melakukan iterasi refactoring atau pemeriksaan kesehatan arsitektur kuartalan.

Contoh PlantUML – Aplikasi API Sistem Perbankan Internet (gaya Classic Big Bank plc)

Berikut adalah contoh tingkat produksi yang menggunakan perpustakaan C4-PlantUML resmi — contoh dunia nyata yang paling sering dirujuk.

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

title Diagram Komponen: Sistem Perbankan Internet - Aplikasi API

' Aktor / bagian eksternal dari tingkat Container
Container(spa, "Aplikasi Halaman Tunggal", "JavaScript & Angular", "Menyediakan antarmuka perbankan internet melalui browser")
Container(mobile, "Aplikasi Seluler", "iOS/Android", "Menyediakan fungsi perbankan seluler terbatas")
ContainerDb(database, "Database Perbankan", "PostgreSQL", "Menyimpan preferensi pengguna, data yang di-cache, sesi")
System_Ext(mainframe, "Sistem Perbankan Inti", "Mainframe – akun dan transaksi inti")

' Container yang sedang kita perbesar
Container_Boundary(api, "Aplikasi API") {
    Component(signInCtrl, "Kontroler Masuk", "Kontroler REST Spring MVC", "Menangani otentikasi & pembuatan sesi")
    Component(accountsCtrl, "Kontroler Ringkasan Akun", "Kontroler REST Spring MVC", "Menyediakan saldo dan ringkasan akun")
    Component(resetPwdCtrl, "Kontroler Atur Ulang Kata Sandi", "Kontroler REST Spring MVC", "Mengelola alur atur ulang kata sandi")
    
    Component(security, "Komponen Keamanan", "Spring Bean", "Token JWT, hash kata sandi, pemeriksaan peran")
    Component(accountService, "Komponen Manajemen Akun", "Spring Bean / Layanan", "Mengoordinasikan permintaan akun & aturan bisnis")
    Component(mainframeFacade, "Fasade Perbankan Mainframe", "Spring Bean", "Lapisan anti-korupsi terhadap mainframe lama")
    Component(emailNotifier, "Komponen Pemberitahuan Email", "Spring Bean", "Mengirim email konfirmasi & atur ulang")
}

' Hubungan di dalam batas
Rel(signInCtrl, security, "Menggunakan")
Rel(accountsCtrl, accountService, "Menggunakan")
Rel(resetPwdCtrl, security, "Menggunakan")
Rel(resetPwdCtrl, emailNotifier, "Menggunakan")
Rel(accountService, mainframeFacade, "Menggunakan")
Rel(accountService, database, "Membaca dari dan menulis ke", "JDBC")
Rel(mainframeFacade, mainframe, "Menggunakan", "XML/HTTPS")
Rel(emailNotifier, database, "Membaca preferensi pengguna", "JDBC")

' Panggilan masuk dari antarmuka depan
Rel(spa, signInCtrl, "Menggunakan", "JSON/HTTPS")
Rel(spa, accountsCtrl, "Menggunakan", "JSON/HTTPS")
Rel(spa, resetPwdCtrl, "Menggunakan", "JSON/HTTPS")
Rel(mobile, signInCtrl, "Menggunakan", "JSON/HTTPS")
Rel(mobile, accountsCtrl, "Menggunakan", "JSON/HTTPS")
Rel(mobile, resetPwdCtrl, "Menggunakan", "JSON/HTTPS")

LAYOUT_WITH_LEGEND()
LAYOUT_LEFT_RIGHT()

@enduml

Ini menghasilkan:

  • Batas yang jelas di sekitar container API

  • Pengelompokan logis dari kontroler, layanan, dan fasade

  • Tanggung jawab yang tepat

  • Interaksi kunci & ketergantungan

  • Legenda otomatis untuk kemudahan pembacaan

Tempel ke renderer PlantUML (online atau IDE) — sesuaikan nama/teknologi sesuai sistem Anda.

Gunakan pola ini sebagai template awal Anda. Tujuannya selalu komunikasi tim yang efektif — bukan keindahan diagram. Selamat merancang!

Sumber Daya Diagram Komponen C4

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