Was ist ein C4-Container-Diagramm?
Das Container-Diagramm istEbene 2 im C4-Modell von Simon Brown. Es zoomt in ein einzelnes Software-System (definiert auf Ebene 1 – Systemkontext) hinein, um Folgendes anzuzeigen:

-
Die Höchstes Niveau der Struktur der Architektur innerhalb Ihrer Systemgrenze.
-
Wichtige bereitstellbare/ausführbare Einheiten genannt Container.
-
Technologieauswahl für jeden Container.
-
Wie Container interagieren miteinander und mit externen Akteuren/Systemen.
Wichtige Klärung: Ein „Container“ im C4-Modellist nicht notwendigerweise ein Docker-Container. Es ist jede separat bereitstellbare/ausführbare Einheit, die Code ausführt oder Daten speichert. Beispiele:
-
Webanwendung / Einseitenanwendung (SPA)
-
Mobile App
-
Serverseitige API / Mikrodienst
-
Datenbank (Schema)
-
Dateispeicherung (S3-Bucket, Dateisystemordner)
-
Nachrichtenbroker / Warteschlange (wenn explizit modelliert)
-
Desktop- / Befehlszeilenanwendung
-
Batch-Prozess / geplanter Job
Das Diagramm bleibt hochrangig — keine internen Klass- oder Code-Details (das sind Ebene-3-Komponenten oder Ebene-4-Code).
Wann man ein Container-Diagramm erstellt
Erstellen (und pflegen) Sie ein Container-Diagramm, wenn:
-
Sie haben das abgeschlossen (oder zumindest skizziert)Systemkontext Diagramm und müssen beantworten: „Was sind die wichtigsten Bausteine innerhalb unseres Systems?“
-
Onboarding neuer Entwickler, Architekten oder Betriebsteammitglieder — sie müssen schnell den Technologie-Stack und die übergeordneten Verantwortlichkeiten verstehen.
-
Wichtige technologische oder architektonische Entscheidungen treffen (Monolithus → Mikrodienste, Hinzufügen einer mobilen App, Datenbankwahl, Einführung von Nachrichtenwarteschlangen, Cloud-Migration).
-
Dokumentation für Audits, Compliance, Sicherheitsüberprüfungen oder Incident-Response (hilft, Angriffsfläche und Datenflüsse zu zeigen).
-
Sie möchten „Architektur als Code“, der im Repository lebt und sich mit dem System weiterentwickelt.
-
Die meisten Teams stoppen hier — Simon Brown selbst stellt fest, dass Systemkontext + Container Diagramme reichen für die Mehrheit der Software-Teams aus. Gehen Sie erst tiefer (Komponenten/Code), wenn die Komplexität innerhalb eines Containers dies rechtfertigt.
Überspringen oder verschieben Sie, wenn:
-
Das System ist äußerst einfach (einer Prozess + Datenbank).
-
Sie befinden sich in einer sehr frühen Ideenphase und benötigen lediglich den Überblick.
Warum Container-Diagramme verwenden? (Wichtige Vorteile)
-
Klarheit für verschiedene Zielgruppen
Entwickler sehen Technologien und Integrationspunkte.
Ops/Infra-Teams sehen bereitstellbare Einheiten und Kommunikationspfade.
Architekten sehen Verantwortlichkeitsgrenzen und Risiken durch technischen Schulden.
Manager sehen eine ausreichend technologieunabhängige, aber dennoch konkrete Sichtweise. -
Vermeidet das „ein großes Diagramm“-Problem
Verhindert, dass alles (Benutzer + Infrastruktur + Klassen + Cloud-Symbole) in ein einziges überlastetes Bild gelegt wird. -
Hebt wichtige Entscheidungen hervor
Zeigt deutlich Entscheidungen wie SPA + API + relationale DB gegenüber serverseitigem Rendern + NoSQL, oder synchron gegenüber ereignisgesteuertem Verhalten. -
Kommunikation und Zusammenarbeit
Dient als gemeinsame Karte während Design-Sitzungen, Incident-Post-Mortems, Bedrohungsmodellierung und Roadmapping. -
Lebendige Dokumentation
Wenn in PlantUML / Structurizr DSL / ähnlich geschrieben → in Git versioniert, automatisch auf CI regeneriert, stets aktuell.
Wie man ein großartiges Container-Diagramm erstellt (Schritt-für-Schritt-Anleitung + Best Practices)
-
Beginnen Sie auf Ebene 1
Kopieren Sie Personen + externe Software-Systeme aus dem Kontextdiagramm — sie werden Akteure, die mit Ihren Containern interagieren. -
Zeichnen Sie die Systemgrenze
Verwenden SieSystem_Grenzein PlantUML, um klar abzugrenzen, was „innerhalb unseres Systems“ liegt. -
Identifizieren Sie Container
Fragen Sie: Was sind die separat ausführbaren/deploybaren Dinge, die die Funktionalität des Systems liefern?
Häufige Muster:-
Web-SPA ↔ API-Backend ↔ Datenbank
-
Mobile App ↔ Backend-for-Frontend (BFF) ↔ Gemeinsame Dienste
-
Mikroservices mit Nachrichtenbroker
-
Veralteter Monolith + neue API-Schicht
-
-
Technologie und kurze Beschreibung hinzufügen
Jeder Container sollte zeigen: Name, Technologie, kurze Zweckangabe.
Halten Sie Beschreibungen unter 15 Wörtern. -
Interaktionen (Beziehungen) definieren
Zeigen Sie Richtung + Protokoll + Absicht (z. B. „JSON/HTTPS“, „Liest aus und schreibt in“, „Veröffentlicht auf“, „Verbraucht von“).
Verwenden Sie Verben in Beziehungen. -
Best Practices
-
Halten Sie es lesbar — zielen Sie auf weniger als 10–12 Container ab. Wenn mehr → erstellen Sie fokussierte Ansichten (z. B. „API-Subsystem-Container“).
-
Seien Sie konsistent — gleiche Layout-Richtung (von oben nach unten / von links nach rechts), gleicher Detailgrad.
-
Verwenden Sie Symbole/Sprites — fügen Sie visuelle Akzente hinzu (PlantUML unterstützt Devicons, Font-Awesome usw.).
-
Legende & Schlüssel — Aktivieren Sie die automatische Legende in PlantUML.
-
Vermeiden Sie Unordnung — Lassen Sie Warteschlangen/Themen weg, wenn sie keinen Mehrwert bieten; beschriften Sie stattdessen die Protokolle auf den Pfeilen.
-
Versionieren und als Code speichern — .puml-Dateien in das Repository committen.
-
Anpassung an die Zielgruppe — Eine Version für Entwickler (detaillierte Technologie), eine leichtere Version für Stakeholder.
-
PlantUML-Beispiel – Klassisches Internet-Banking-System (Stil von Big Bank plc)
Hier ist ein sauberes, produktionsreifes Beispiel unter Verwendung der offiziellen C4-PlantUML-Bibliothek.
@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml
' Optional: schöne Symbole hinzufügen (aus tupadr3-Sprites)
!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
!include https://raw.githubusercontent.com/tupadr3/plantuml-icon-font-sprites/master/devicons/android.puml
title Container-Diagramm: Internet-Banking-System
Person(kunde, "Privatkundenkunde", "Ein Kunde von Big Bank plc")
System_Boundary(c1, "Internet-Banking-System") {
Container(spa, "Einseiten-App", "JavaScript & Angular", "Bietet allen Kunden über ihren Webbrowser die gesamte Internet-Banking-Funktionalität", $sprite="angular")
Container(mobil, "Mobile App", "Android/iOS (React Native)", "Eingeschränkte Internet-Banking-Funktionalität", $sprite="android")
Container(api, "API-Anwendung", "Java & Spring Boot", "Bietet Internet-Banking-Funktionalität über eine API", $sprite="java")
ContainerDb_Ext(db, "Bankdatenbank", "PostgreSQL", "Speichert Benutzereinstellungen, zwischengespeicherte Daten, Sitzungen (Kernkonten/Transaktionen verbleiben im Mainframe)", $sprite="postgresql")
}
System_Ext(kern, "Kern-Banking-System", "Mainframe-System – bestehend")
System_Ext(email, "E-Mail-System", "Versendet E-Mails (z. B. AWS SES)")
Rel(kunde, spa, "Nutzt", "HTTPS")
Rel(kunde, mobil, "Nutzt", "HTTPS")
Rel(spa, api, "Ruft auf", "JSON/HTTPS")
Rel(mobil, api, "Ruft auf", "JSON/HTTPS")
Rel(api, db, "Liest aus und schreibt in", "JDBC/SQL")
Rel(api, kern, "Nutzt", "JSON/HTTPS")
Rel(api, email, "Versendet E-Mail mit", "HTTPS")
LAYOUT_WITH_LEGEND()
LAYOUT_TOP_DOWN()
@enduml
Dies erzeugt ein sauberes Diagramm mit:
-
Systemgrenze
-
Technologiebeschriftungen
-
Sprites/Symbole
-
Klare Beziehungen
-
Legende
Sie können es direkt in den PlantUML-Online-Server oder jedes kompatible IDE-/Editor-Programm einfügen.
Verwenden Sie diese Struktur als Vorlage – ersetzen Sie die Elemente durch Namen, Technologien und Flüsse Ihres eigenen Systems. Für erweiterte Gestaltungsoptionen (Themen, benutzerdefinierte Farben) prüfen Sie die GitHub-Beispiele der C4-PlantUML-Bibliothek.
Viel Spaß beim Zeichnen von Diagrammen – und denken Sie daran: Ziel ist effektive Kommunikation, nicht UML-Perfektion!
Ressource für C4-Container-Diagramme
- Der ultimative Leitfaden zur C4-Modellvisualisierung mit den KI-Tools von Visual Paradigm: Dieser Leitfaden erklärt, wie Sie KI-gestützte Werkzeuge nutzen, um die Visualisierung des C4-Modells zu automatisieren und zu verbessern, um die Softwarearchitektur schneller zu gestalten.
- Nutzen Sie Visual Paradigms AI C4 Studio zur vereinfachten Architekturdokumentation: Dieser Artikel beschreibt die Nutzung eines KI-optimierten Studios zur Erstellung sauberer, skalierbarer und wartbarer Dokumentation der Softwarearchitektur.
- Der ultimative Leitfaden zum C4-PlantUML Studio: Die Revolutionierung der Softwarearchitekturgestaltung: Diese Ressource untersucht die Kombination von KI-getriebener Automatisierung, der Klarheit des C4-Modells und der Flexibilität von PlantUML zu einem einzigen leistungsstarken Werkzeug.
- Ein umfassender Leitfaden zu Visual Paradigms KI-gestütztem C4-PlantUML Studio: Diese Anleitung beschreibt ein speziell entwickeltes Werkzeug, das Ende 2025 veröffentlicht wurde und natürliche Sprachprompts in mehrschichtige C4-Diagramme umwandelt.
- C4-PlantUML Studio | KI-gesteuerter C4-Diagramm-Generator: Diese Übersicht der Funktionen hebt ein KI-getriebenes Werkzeug hervor, das entwickelt wurde, um C4-Softwarearchitekturdiagramme aus einfachen Textbeschreibungen zu generieren.
- Erzeugen und Ändern von C4-Komponentendiagrammen mit dem Visual Paradigm KI-Chatbot: Dieser Tutorial zeigt, wie ein KI-gestützter Chatbot verwendet wird, um iterativ die Komponentenebene der Architektur komplexer Systeme zu erstellen und zu verfeinern.
- KI-gestützter C4-Diagramm-Generator: Kernlevel und unterstützende Ansichten: Diese Seite erklärt, wie der KI-Generator die vier Kernlevel des C4-Modells – Kontext, Container, Komponente und Bereitstellung – unterstützt, um umfassende Dokumentation bereitzustellen.
- KI-Diagramm-Generator: Release mit vollständiger C4-Modellunterstützung: Dieses Update beschreibt die Integration von KI-gestützten Funktionen für die automatisierte Erstellung hierarchischer C4-Modell-Diagramme.
- C4-Modell-KI-Generator: Automatisierung des gesamten Modellierungslebenszyklus: Diese Ressource hebt hervor, wie ein spezialisierter KI-Chatbot konversationelle Prompts nutzt, um Konsistenz in der Architekturdokumentation für DevOps-Teams zu gewährleisten.
- Umfassende Bewertung: Generische KI-Chatbots im Vergleich zu Visual Paradigms C4-Tools: Dieser Vergleich erklärt, warum spezialisierte Werkzeuge wie die C4-PlantUML Studio strukturiertere und professionellere Ergebnisse liefern als allgemeine Sprachmodelle.
Der Artikel ist auch in English, Español, فارسی, 日本語, Portuguese and Ру́сский verfügbar.






