de_DEen_US

C4-Modell Ebene 3 Tiefgang: Komponenten-Diagramme meistern, um interne Struktur und Verantwortlichkeiten aufzudecken

Was ist ein C4-Komponentendiagramm?

Das Komponentendiagramm istEbene 3im C4-Modell von Simon Brown. Es zoomt in aufeinen bestimmten Container (aus dem Containerdiagramm der Ebene 2) um Folgendes zu zeigen:

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

  • Dielogischen Bausteine (Komponenten), aus denen dieser Container besteht.

  • Wie diese Komponentenmiteinander interagierenuntereinander.

  • Verantwortlichkeiten undImplementierungstechnologien (auf einer höheren Ebene als Klassen – denken Sie an Spring-Beans, Module, Dienste, Controller, Fassaden usw.).

  • WichtigeSchnittstellen oderVerträge zwischen Komponenten (häufig über Beziehungen impliziert).

Wichtige Klärung: Eine „Komponente“ im C4 istnichteine Klasse. Sie ist einelogische Gruppierung von Klassen hinter einer gut definierten Schnittstelle – etwas mit klarer Verantwortung, das teilweise unabhängig entwickelt/getestet/bereitgestellt werden kann (innerhalb des Containers), abernicht separat bereitstellbar wie ein Container.

Beispiele für Komponenten:

  • REST-Controller / Web-Controller

  • Service / Use Case / Anwendungsservice

  • Repository / Datenzugriffsobjekt

  • Domänenmodell / Entität

  • Sicherheit / Authentifizierungsmodul

  • Benachrichtigungssender

  • Facade für externe Systeme

  • Geschäftsregel-Engine

  • Caching-Ebene

Das Diagramm bleibt logisch / implementierungsunabhängig genug — keine Klassenattribute, Methodensignaturen oder vollständigen UML-Klassendetails (das ist Level-4-Code, der optional und selten ist).

Wann ein Komponentendiagramm erstellt werden sollte

Erstellen (und pflegen) eines Komponentendiagramms nur wenn:

  • Der gewählte Container ist komplex genug dass seine interne Struktur nicht allein aus Namen und Beschreibung ersichtlich ist.

  • Neue Teammitglieder (insbesondere Backend-Entwickler) fragen häufig: „Wie wird Funktion X tatsächlich innerhalb dieses Dienstes/API implementiert?“

  • Sie sind Refactoring, Aufteilung, oder Extrahieren Logik innerhalb eines Containers und müssen Grenzen/Zuständigkeiten klären.

  • Sie führen detaillierte Designbesprechungen, Code-Reviews, oder On-Call-Übergaben für einen bestimmten Container.

  • Sie möchten dokumentieren wichtige architektonische Entscheidungen innerhalb eines Containers (z. B. hexagonale Architektur, vertikaler Slice, Trennung von CQRS, Sicherheits-Enforcement-Punkt).

  • Sie haben identifiziert technische Schuld, Gott-Klassen, oder enge Kopplung innerhalb eines Containers und möchten den Zustand vor der Bereinigung visualisieren.

  • Sie onboarden erfahrene Entwickler/Architekten, die die Modulstruktur schnell verstehen müssen.

TUN SIE NICHT Komponentendiagramme für folgendes erstellen:

  • Einfache Container (CRUD-API mit einem Controller + einer Service-Komponente + einer Repository-Komponente – offensichtliche Struktur).

  • Die meisten Microservices (oft so klein, dass die Container-Ebene ausreicht).

  • Frontend-Container (React/Vue-Anwendungen – meist besser mit Komponentenbäumen oder Storybook dargestellt).

  • Wenn Ebene 2 (Container) zusammen mit guter Code-Struktur/Namenskonvention bereits alles kommuniziert, was benötigt wird.

Simon Brown empfiehlt: Die meisten Teams können bei Ebene 1 + 2 bleiben. Gehen Sie nur bei den folgenden Ebenen 3: die komplizierten / riskanten / zentralen / hochfrequenten Container.

Warum Komponentendiagramme verwenden? (Wichtige Vorteile)

  • Klärt interne Verantwortlichkeiten — Zeigt die Trennung der Verantwortlichkeiten (z. B. Controller vs Services vs Datenzugriff vs externe Integration).

  • Deckt Kopplung und Abhängigkeiten auf — Zeigt Gottes-Komponenten, zyklische Abhängigkeiten oder übermäßige Abhängigkeit von Infrastruktur-Code sichtbar.

  • Unterstützt eine bessere Einarbeitung und Übergaben — Entwickler verstehen Modul-Grenzen schneller als das Lesen aller Quelldateien.

  • Leitet Refactoring und Evolution an — Visueller Baseline vor/nach der Aufspaltung von Monolithen oder Einführung von Mustern (Ports & Adapter, vertikale Slices).

  • Ermöglicht Architektur-Reviews und Bedrohungsmodellierung — Identifiziert, wo Validierung, Autorisierung, Protokollierung usw. stattfinden.

  • Architektur als Code — Wenn in PlantUML gespeichert → mit dem Codebase versioniert, vergleichbar, in PRs überprüfbar.

  • Skaliert die Kommunikation — Senior-Entwickler kümmern sich um Komponentenverantwortlichkeiten; Junior-Entwickler kümmern sich darum, wo neuer Code hingehört.

Wie man ein großartiges Komponentendiagramm erstellt (Schritt-für-Schritt-Anleitung + Best Practices)

  1. Wählen Sie EINEN Container — Beginnen Sie mit dem komplexesten oder geschäftskritischsten (häufig der Haupt-API-/Backend-Service).

  2. Kopieren Sie den Kontext von Ebene 2 — Fügen Sie externe Akteure (andere Container, Personen, externe Systeme) hinzu, die mit diesem Container interagieren.

  3. Zeichnen Sie die Container-Grenze — Verwenden Sie Container_Grenze in PlantUML, um klar zu definieren, was „innerhalb dieses Containers“ liegt.

  4. Identifizieren Sie Komponenten — Fragen Sie:

    • Welche sind die wichtigsten Module / Spring-Beans / Pakete / begrenzten Kontexte innerhalb?

    • Wo landen eingehende Anfragen? (Controller/Handler)

    • Wo wird die Geschäftslogik orchestriert?

    • Wo wird Daten zugegriffen / zwischengespeichert / validiert?

    • Wo werden Querschnittsaspekte behandelt? (Sicherheit, Protokollierung)

    • Gibt es Fassaden / Anti-Korruptionsschichten zu Legacy-/externen Systemen?

  5. Technologie und kurze Beschreibung hinzufügen — Name, Technologie (Spring-Service, .NET-Handler, Go-Modul usw.), kurze Zweckangabe (< 15 Wörter).

  6. Wechselwirkungen definieren — Richtung und Absicht anzeigen (Verwendet, Ruft auf, Liest von, Veröffentlicht Ereignisse an). Das Protokoll wird auf dieser Ebene oft weggelassen.

  7. Best Practices

    • Umfang begrenzen — Maximal 6–12 Komponenten pro Diagramm. Bei mehr → fokussierte Unterdarstellungen erstellen (z. B. „Authentifizierungs-Slice“).

    • Sinnvoll benennen — Bevorzugen Sie „Order Placement Service“ anstelle von „OrderService“.

    • Verantwortlichkeiten anzeigen, nicht Klassen — Vermeiden Sie die Auflistung jeder Klasse; gruppieren Sie logisch.

    • Symbole sparsam verwenden — Nur wenn sie die Technologie klären (Spring-, .NET-Symbole).

    • Legende aktivieren — Hilft neuen Lesern.

    • Layout sauber halten — LAYOUT_MIT_LEGENDEN(), LAYOUT_OBEN_UNTEN().

    • Version im Repository — .puml-Dateien neben dem Container-Code.

    • Iterieren — Aktualisieren Sie während Refactoring-Spikes oder quartalsweisen Architektur-Check-ups.

PlantUML-Beispiel – Internet-Banking-System-API-Anwendung (klassischer Big Bank plc-Stil)

Hier ist ein Produktions-Beispiel unter Verwendung der offiziellen C4-PlantUML-Bibliothek – das am häufigsten zitierte echte Beispiel.

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

title Komponentendiagramm: Internet-Banking-System - API-Anwendung

' Akteure / externe Teile auf Container-Ebene
Container(spa, "Einzelseiten-Anwendung", "JavaScript & Angular", "Bietet Internet-Banking-Oberfläche über Browser")
Container(mobile, "Mobile App", "iOS/Android", "Bietet eingeschränkte mobile Bankfunktionen")
ContainerDb(database, "Bankdatenbank", "PostgreSQL", "Speichert Benutzereinstellungen, zwischengespeicherte Daten, Sitzungen")
System_Ext(mainframe, "Kernbank-System", "Mainframe – Kernkonten & Transaktionen")

' Der Container, in den wir hineinzoomen
Container_Boundary(api, "API-Anwendung") {
    Component(signInCtrl, "Anmelde-Controller", "Spring MVC REST-Controller", "Verwaltet Authentifizierung & Sitzungserstellung")
    Component(accountsCtrl, "Konten-Zusammenfassungs-Controller", "Spring MVC REST-Controller", "Bietet Kontostände & Zusammenfassungen")
    Component(resetPwdCtrl, "Passwort-Zurücksetzungs-Controller", "Spring MVC REST-Controller", "Verwaltet Ablauf des Passwort-Zurücksetzens")
    
    Component(security, "Sicherheitskomponente", "Spring-Bean", "JWT-Tokens, Passwort-Hashing, Rollenprüfungen")
    Component(accountService, "Kontoverwaltungs-Komponente", "Spring-Bean / Service", "Orchestriert Kontenabfragen & Geschäftsregeln")
    Component(mainframeFacade, "Mainframe-Bank-Fassade", "Spring-Bean", "Anti-Korruptionsschicht für Legacy-Mainframe")
    Component(emailNotifier, "E-Mail-Benachrichtigungs-Komponente", "Spring-Bean", "Sendet Bestätigungs- & Zurücksetzungs-E-Mails")
}

' Beziehungen innerhalb der Grenze
Rel(signInCtrl, security, "Verwendet")
Rel(accountsCtrl, accountService, "Verwendet")
Rel(resetPwdCtrl, security, "Verwendet")
Rel(resetPwdCtrl, emailNotifier, "Verwendet")
Rel(accountService, mainframeFacade, "Verwendet")
Rel(accountService, database, "Liest von und schreibt in", "JDBC")
Rel(mainframeFacade, mainframe, "Verwendet", "XML/HTTPS")
Rel(emailNotifier, database, "Liest Benutzereinstellungen", "JDBC")

' Eingehende Aufrufe von Frontends
Rel(spa, signInCtrl, "Verwendet", "JSON/HTTPS")
Rel(spa, accountsCtrl, "Verwendet", "JSON/HTTPS")
Rel(spa, resetPwdCtrl, "Verwendet", "JSON/HTTPS")
Rel(mobile, signInCtrl, "Verwendet", "JSON/HTTPS")
Rel(mobile, accountsCtrl, "Verwendet", "JSON/HTTPS")
Rel(mobile, resetPwdCtrl, "Verwendet", "JSON/HTTPS")

LAYOUT_MIT_LEGENDEN()
LAYOUT_LINKS_RECHTS()

@enduml

Dies ergibt:

  • Klare Grenze um den API-Container

  • Logische Gruppierung von Controllern, Services und Facades

  • Genau definierte Verantwortlichkeiten

  • Wichtige Wechselwirkungen und Abhängigkeiten

  • Automatische Legende für bessere Lesbarkeit

Einfügen in PlantUML-Renderer (online oder IDE) – Anpassen von Namen/Technologien für Ihr System.

Verwenden Sie dieses Muster als Ausgangsvorlage. Das Ziel ist immer effektive Teamkommunikation – nicht Diagrammschönheit. Viel Spaß beim Modellieren!

Ressource für C4-Komponenten-Diagramme

Der Artikel ist auch in English verfügbar.