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, فارسی, Français, English, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文 verfügbar.













