de_DEen_USes_ESfa_IRfr_FRhi_INid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

Die C4-Modell, entwickelt von Simon Brown, ist ein leistungsfähiger, hierarchischer Ansatz zur Visualisierung von Softwarearchitekturen. Er verwendet vier Abstraktionsstufen, um die richtige Detailtiefe für unterschiedliche Zielgruppen, von Geschäftssachverständigen bis zu Entwicklern, bereitzustellen. Dadurch eignet er sich ideal für die Erstellung klarer, wartbarer und zielgruppengerechter Dokumentation.

Introduction to C4 Model: a Quick Guide - Visual Paradigm Blog

Dieser umfassende Leitfaden greift auf die bekannte Fallstudie von Big Bank plc’s Internet-Banking-System — ein fiktives, aber realistisches Beispiel für die Entwicklung einer Online-Banking-Plattform für private Kunden, um Konten einzusehen und Zahlungen vorzunehmen. Die Fallstudie zeigt, wie das C4-Modell schrittweise angewendet wird, unter Verwendung von PlantUML für „Architektur als Code“. Er integriert außerdem moderne Werkzeuge wie Visual Paradigm’s KI-gestütztes C4-PlantUML-Studio (im späten Jahr 2025 veröffentlicht) zur Beschleunigung der Erstellung und Pflege.

Übersicht über das C4-Modell

Das Modell umfasst vier Ebenen:

  1. Ebene 1: Systemkontext — Das große Ganze: das System, die Benutzer und externe Abhängigkeiten.

  2. Ebene 2: Container — Hauptbereitstellbare Einheiten (Anwendungen, Dienste, Datenbanken) und hochrangige Technologieentscheidungen.

  3. Ebene 3: Komponenten — Interne logische Bausteine innerhalb eines Containers.

  4. Ebene 4: Code — Optionale Details auf niedriger Ebene (z. B. Klassen); werden oft übergangen zugunsten von Quellcode-Verweisen.

Zusätzliche unterstützende Ansichten umfassen dynamische (Laufzeitflüsse) und Bereitstellungsdiagramme.

Anwendung des C4-Modells: Fallstudie zum Internet-Banking-System von Big Bank plc

Ebene 1: Systemkontext-Diagramm

Zweck: Ein hochrangiges Überblicksdiagramm für Geschäftssachverstandige und nicht-technische Zielgruppen bereitstellen, das zeigt, wie das Internet-Banking-System in die umfassendere Umgebung passt, ohne technische Fachbegriffe zu verwenden.

Wichtige Elemente:

  • Person: Privatkundenkunde — Ein Kunde mit einem oder mehreren privaten Bankkonten.

  • Software-System: Internet-Banking-System — Ermöglicht Kunden, Kontoinformationen einzusehen und Zahlungen vorzunehmen.

  • Externe Systeme:

    • Kernbank-System (bestehende Mainframe-Systeme) — Verwaltet Kundendaten, Konten und Transaktionen.

    • E-Mail-System (z. B. AWS SES) — Versendet Bestätigungen und Benachrichtigungen.

Beziehungen:

  • Kunde nutzt das Internet-Banking-System.

  • Internet-Banking-System nutzt das Kernbank-System für Daten und Transaktionen.

  • Internet-Banking-System versendet E-Mail über das E-Mail-System.

Diese Ebene hält die Dinge einfach und macht den Umfang sowie die Integrationen deutlich.

PlantUML-Beispiel (abgewandelte Version aus der Fallstudie):

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml
LAYOUT_TOP_DOWN()
LAYOUT_WITH_LEGEND()
title Systemkontext-Diagramm (Ebene 1) für das Internet-Banking-System
Person(kunde, "Privatkundenkunde", "Ein Kunde mit einem oder mehreren privaten Bankkonten.")
System(internet_banking_system, "Internet-Banking-System", "Ermöglicht Kunden, Konten einzusehen und Zahlungen vorzunehmen.")
System(kernbank_system, "Kernbank-System", "Bestehendes Mainframe-System zur Verwaltung von Kundendaten, Konten und Transaktionen.")
System_Ext(email_system, "E-Mail-System", "Amazon Web Services Simple Email Service (AWS SES) zur Versendung von Bestätigungen.")
Rel(kunde, internet_banking_system, "Nutzt")
Rel(internet_banking_system, kernbank_system, "Nutzt")
Rel(internet_banking_system, email_system, "Versendet E-Mail über")
@enduml

Ebene 2: Container-Diagramm

Zweck: Vergrößerung, um die wichtigsten Bausteine (Container) und Technologieauswahlen darzustellen, gerichtet an Architekten, Entwickler und DevOps-Teams.

Wichtige Elemente (innerhalb der Grenzen des Internet-Banking-Systems):

  • Single-Page-Anwendung (SPA) — JavaScript + Angular, vollständige Benutzeroberfläche im Webbrowser.

  • Mobile App — iOS/Android mit React Native (oder ähnlich), eingeschränkte Funktionalität.

  • API-Anwendung — Java + Spring Boot, JSON/HTTPS-API, die beide Frontends bedient.

  • Datenbank — PostgreSQL, speichert Sitzungsdaten, Einstellungen und zwischengespeicherte Zusammenfassungen (Kerndaten bleiben im Mainframe).

Extern — Kernbankensystem und E-Mail-System.

Beziehungen:

  • Der Kunde nutzt SPA und Mobile-App über HTTPS.

  • SPA und Mobile-App rufen die API-Anwendung auf (JSON/HTTPS).

  • Die API-Anwendung liest/schreibt in die Datenbank (JDBC/SQL).

  • Die API-Anwendung kommuniziert mit dem Kernbankensystem (JSON/HTTPS) und dem E-Mail-System (HTTPS).

Dieses Diagramm dient als die „einzige Quelle der Wahrheit“ für technologische Entscheidungen.

PlantUML-Beispiel (Verwendung von Sprites für Symbole):

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml
!include https://raw.githubusercontent.com/tupadr3/plantuml-icon-font-sprites/master/devicons/angular.puml
!include https://raw.githubusercontent.com/tupadr3/plantuml-icon-font-sprites/master/devicons/java.puml
!include https://raw.githubusercontent.com/tupadr3/plantuml-icon-font-sprites/master/devicons/postgresql.puml
LAYOUT_TOP_DOWN()
LAYOUT_WITH_LEGEND()

title C4-Container-Diagramm für das Internet-Banking-System
Person(kunde, "Privatkundenkunde", "Ein Kunde mit einem oder mehreren privaten Bankkonten.")
System_Boundary(internet_banking_system, "Internet-Banking-System") {
    Container(spa, "Einseitenanwendung", "JavaScript + Angular", "Vollständige Internet-Banking-Oberfläche", $sprite="angular")
    Container(mobile_app, "Mobile-App", "iOS/Android (React Native)", "Eingeschränkte Funktionalität", $sprite="react")
    Container(api_app, "API-Anwendung", "Java + Spring Boot", "JSON/HTTPS-API", $sprite="java")
    ContainerDb(database, "Datenbank", "PostgreSQL", "Sitzungsdaten, Einstellungen, zwischengespeicherte Zusammenfassungen", $sprite="postgresql")
}
System(kernbankensystem, "Kernbankensystem", "Vorhandenes Mainframe...")
System_Ext(email_system, "E-Mail-System", "AWS SES...")
Rel(kunde, spa, "Nutzt", "HTTPS")
Rel(kunde, mobile_app, "Nutzt", "HTTPS")
Rel(spa, api_app, "Ruft auf", "JSON/HTTPS")
Rel(mobile_app, api_app, "Ruft auf", "JSON/HTTPS")
Rel(api_app, database, "Liest aus und schreibt in", "JDBC/SQL")
Rel(api_app, kernbankensystem, "Abfragen / Aktualisieren", "JSON/HTTPS")
Rel(api_app, email_system, "Sendet E-Mail über", "HTTPS")
@enduml

Ebene 3: Komponentendiagramm

Zweck: Detailierte Darstellung der internen Struktur eines zentralen Containers (hier: die API-Anwendung) für Entwicklungsteams.

Wichtige Komponenten (im Inneren der API-Anwendung):

  • Kontroll-Controller (Spring MVC) — Stellt Zusammenfassungen und Kontostände bereit.

  • Authentifizierungs-Controller (Spring MVC) — Anmeldung, Sitzungen, Tokens.

  • Passwort-Zurücksetzungs-Controller (Spring MVC) — Passwortzurücksetzung per E-Mail.

  • Sicherheitskomponente (Spring-Bean) — Authentifizierung, JWT, Hashing.

  • Kontomanagement-Komponente (Spring-Bean) — Koordiniert Aufrufe des Kernbankensystems.

  • E-Mail-Benachrichtigungs-Komponente (Spring-Bean) — Versendet E-Mails.

Interaktionen — Controller nutzen Sicherheit; Kontomanagement nutzt Kernbankensystem; E-Mail nutzt Datenbank; Frontends rufen Controller auf.

PlantUML-Beispiel:

PlantUML Diagram

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/C4-PlantUML/master/C4_Component.puml
LAYOUT_WITH_LEGEND()
title Komponentendiagramm für das Internet-Banking-System – API-Anwendung
Container(spa, "Einzelseitenanwendung", "javascript und angular", "...")
Container(ma, "Mobile App", "...", "...")
ContainerDb(db, "Datenbank", "...", "...")
System_Ext(mbs, "Mainframe-Bankensystem", "...")
Container_Boundary(api, "API-Anwendung") {
    Component(accounts, "Kontrolller für Konten", "Spring MVC", "...")
    Component(auth, "Authentifizierungs-Kontroller", "Spring MVC", "...")
    Component(reset, "Passwort-Zurücksetzungs-Kontroller", "Spring MVC", "...")
    Component(security, "Sicherheitskomponente", "Spring Bean", "...")
    Component(accountmgmt, "Komponente zur Kontoverwaltung", "Spring Bean", "...")
    Component(email, "Komponente für E-Mail-Benachrichtigungen", "Spring Bean", "...")
    Rel(accounts, security, "Verwendet")
    Rel(auth, security, "Verwendet")
    Rel(reset, security, "Verwendet")
    Rel(accountmgmt, mbs, "Verwendet", "XML/HTTPS")
    Rel(email, db, "Liest", "JDBC")
}
Rel(spa, accounts, "Verwendet", "JSON/HTTPS")
Rel(spa, auth, "Verwendet", "JSON/HTTPS")
Rel(spa, reset, "Verwendet", "JSON/HTTPS")
Rel(ma, accounts, "Verwendet", "JSON/HTTPS")
Rel(ma, auth, "Verwendet", "JSON/HTTPS")
Rel(ma, reset, "Verwendet", "JSON/HTTPS")
@enduml

Ebene 4: Code-Diagramm (optional)

Zweck: Zeigt Klassenebene-Details für bestimmte Bereiche an (z. B. Authentifizierung).

Häufig weggelassen – stattdessen auf den Quellcode verweisen.

Beispiel — UML-Klassendiagramm für die Authentifizierung:

  • AuthenticationController verwendet JwtTokenProvider und UserRepository.

PlantUML-Beispiel:

@startuml
classDiagram
class "AuthenticationController" {
    +login(credentials)
    +refreshToken()
}
class "JwtTokenProvider" {
    +generateToken(user)
    +validateToken(token)
}
class "UserRepository" {
    +findByUsername()
}
AuthenticationController ..> JwtTokenProvider : "verwendet"
AuthenticationController ..> UserRepository : "verwendet"
@enduml

Unterstützende Ansichten

  • Dynamisches Diagramm (z. B. „Kontenübersicht anzeigen“-Sequenz): Kunde → SPA → API → Datenbank/Kernbankwesen → Antwort.

  • Bereitstellungsdiagramm: Ordnet Container der Infrastruktur zu (z. B. AWS EC2 für API, RDS für Datenbank, vor Ort befindliches Mainframe).

Nutzen von Visual Paradigms KI-gestützten Tools

Visual Paradigms KI-gestützter C4-PlantUML-Studio (Ende 2025) revolutioniert diesen Prozess:

  • Geben Sie natürliche Sprache ein (z. B. „Erstellen Sie ein C4-Modell für ein Internet-Banking-System mit SPA, Mobile App, Spring Boot API, PostgreSQL und Mainframe-Integration“).

  • Die KI generiert PlantUML-Code und Diagramme für alle Ebenen.

  • Verwenden Sie den KI-Chatbot, um zu iterieren (z. B. „Fügen Sie MFA zur Authentifizierungskomponente hinzu“ oder „Generieren Sie die Bereitstellungsansicht auf AWS“).

  • Stellen Sie Konsistenz über alle Ebenen hinweg sicher und unterstützen Sie die „lebende Dokumentation“.

  • Exportieren, Versionsverwaltung und Integration mit Repositories.

Dieses Tool liefert strukturierte, C4-konforme Ausgaben weitaus zuverlässiger als allgemeine KI-Tools.

Best Practices

  1. Beginnen Sie mit Workshops — Verwenden Sie Whiteboards für Ebene 1, um die Stakeholder auszurichten.

  2. Behandle Architektur als Code — Speichern Sie PlantUML-Dateien in Ihrem Repository, um automatische Aktualisierungen bei Codeänderungen zu erhalten.

  3. Automatisieren mit KI — Verwenden Sie Visual Paradigm, um Diagramme schnell zu generieren und zu verfeinern.

  4. Zielgruppenorientierung — Unterlassen Sie technische Details auf Ebene 1; fügen Sie sie schrittweise hinzu.

  5. Halten Sie es leichtgewichtig — Detailieren Sie komplexe Container nur auf Ebene 3; überspringen Sie Ebene 4, es sei denn, sie ist unbedingt erforderlich.

  6. Entwickeln Sie die Dokumentation weiter — Machen Sie Diagramme zu „lebenden“ Dokumenten, um veraltete Artefakte zu vermeiden.

Der Fallstudienfall von Big Bank plc bleibt ein kanonisches Beispiel für die Wirksamkeit des C4-Modells in realen Szenarien, das Klarheit, Zusammenarbeit und skalierbare Architekturkommunikation fördert. Weitere Informationen finden Sie auf der offiziellen C4-Website oder bei den KI-Tools von Visual Paradigm.

Der Artikel ist auch in English, Español, فارسی, Français, English, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文 verfügbar.