C4-Modell
Das C4-Modell beschreibt Software in mehreren Ebenen: Systemkontext, Container, Komponenten und Code. Jede Ebene beantwortet eine andere Frage und kann eigenständig lesbar bleiben.
- SystemkontextWer nutzt es, wer ist Nachbar?
- ContainerAusführbare oder speichernde Einheiten.
- KomponentenVerantwortungen innerhalb einer Einheit.
Einordnung
Warum das wichtig ist
Ein Diagramm, das Systemgrenze, Module und Klassen mischt, beantwortet keine Frage richtig. C4 trennt die Ebenen, sodass jede Leserfrage ein passendes Bild bekommt. Die Verteilung auf Infrastruktur zeigt eine eigene Sicht.
Dieser Baustein behandelt Abstraktionsebenen und ihren Zweck. Systemkontext vertieft Akteure und Grenze; Verteilungssicht ordnet Laufzeit und Infrastruktur zu.
Auf einen Blick · Vier Zoomstufen der Architektur
Derselbe Shop, drei C4-Ebenen
Der Shop ist ein System mit Browsern, einem externen Zahlungsanbieter und einer Shop-Anwendung. Eine Containeransicht zeigt Shop-Anwendung und Datenbank; erst die Komponentenebene zerlegt die Anwendung in Module.
So liest du das Bild
- Systemkontext Reiter 1: der Shop als eine Box zwischen Kunde und Partnern.
- Container Reiter 2: Shop-Anwendung und Shop-Datenbank.
- Komponenten Reiter 3: die sieben Module in der Shop-Anwendung.
Systemkontext
- Zeigt
- Den Shop als eine Box mit Kunden und Nachbarsystemen.
- Lässt weg
- Alles, was im Shop steckt.
- Zahlungsanbieter
- Nachbarsystem außerhalb der Grenze.
Container
- Zeigt
- Shop-Anwendung und Datenbank mit ihren Verbindungen.
- Lässt weg
- Module in der Anwendung und Klassen.
- Zahlungsanbieter
- Externes System, das von der Anwendung per API aufgerufen wird.
Komponenten
- Zeigt
- Die sieben Module und wer wen aufruft.
- Lässt weg
- Datenbank und Klassen im Modul.
- Zahlungsanbieter
- Ziel eines einzigen Pfeils aus dem Zahlungsmodul.
Nutzen & Grenzen
Hilft, wenn
- Zielgruppen profitieren von vergleichbaren Ebenen zwischen Systemüberblick und interner Struktur.
- Mehrere Systeme lassen sich mit einer gemeinsamen Begrifflichkeit und Abstraktion beschreiben.
Grenzen
- C4 zeigt Struktur, keinen Ablauf; zeitliche Reihenfolgen und Fehlerpfade zeigt die Sequenz.
- Die Code-Ebene veraltet schnell; sie wird nur für einzelne wichtige Stellen gezeichnet.
- Wo die Software läuft, zeigt C4 nicht; das leistet die Verteilungssicht.
In der Praxis
- Zielgruppe und Abstraktion wählen. Bestimme, welche Frage das Diagramm beantworten soll und welche Ebene dafür ausreicht. Benenne Systemgrenze und betrachteten Stand. Das Ergebnis ist eine Sicht mit erkennbarem Zweck.
- Elemente und Beziehungen modellieren. Verwende passende C4-Begriffe und beschrifte Verantwortlichkeiten sowie Kommunikationsbeziehungen. Prüfe, dass Elemente auf derselben Ebene vergleichbar sind. Damit bleibt die Darstellung verständlich und strukturell konsistent.
- Sichten abgleichen und gezielt vertiefen. Vergleiche Kontext, Container und Komponenten auf widersprüchliche Namen und Grenzen. Ergänze feinere Ebenen nur bei verbleibendem Informationsbedarf. Das Ergebnis ist ein abgestimmter Architekturüberblick ohne unnötige Details.
Ausführliche Erklärung lesen
Das C4-Modell beschreibt statische Struktur auf vier Ebenen: Systemkontext, Container, Komponenten und Code. Container bezeichnet im C4-Modell eine ausführbare Anwendung oder einen Datenspeicher und beschreibt damit eine Architekturebene. Jede Ebene beantwortet eine andere Frage und kann als passende Architektursichten in eine gemeinsame arc42 eingeordnet werden.
Die Abstraktion wird nur so weit vertieft, wie eine konkrete Frage es verlangt. Beziehungen und Verantwortlichkeiten werden auf jeder Ebene verständlich benannt. Dynamische Abläufe erklären Nachrichtenreihenfolgen; Verteilungssichten ordnen Software konkreten Laufzeitumgebungen zu. Beide ergänzen die statischen C4-Strukturebenen. Ein Diagramm muss seinen Geltungsbereich und seine Zielgruppe erkennen lassen, damit unterschiedliche Ebenen nicht in einer überladenen Darstellung vermischt werden. Kontext- und Containersichten bilden häufig den Einstieg; Komponenten- und Codeebene vertiefen ausgewählte Fragen. Dynamik und Verteilung bleiben ergänzende Sichten für andere Fragestellungen.
Simon Brown hat das C4-Modell entwickelt; seine Ebenen heißen Context, Container, Component und Code.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welche laufenden Einheiten zeigt die Container-Ebene?
Lösung mit Begründung ansehen
Die Shop-Anwendung und die Shop-Datenbank. Browser und Zahlungsanbieter stehen außen; die Module zeigt erst die Komponentenebene.
AnwendenAuf eine neue Lage übertragen
Ein Partner will wissen, welche externen Systeme der Shop nutzt. Welche Ebene zeigst du ihm?
Lösung mit Begründung ansehen
Den Systemkontext. Dort stehen Kunde, Shop und Zahlungsanbieter, ohne Module oder Code.
BewertenEine Alternative abwägen
Das Team will alle Module, Klassen und Nachbarsysteme in ein einziges Diagramm legen. Was ist der Vorteil, was der Nachteil?
Lösung mit Begründung ansehen
Ein Diagramm gibt alles auf einen Blick. Es beantwortet aber keine einzelne Leserfrage klar und wird schnell unlesbar; getrennte Ebenen bleiben je für sich verständlich.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- C4 – System context diagram (öffnet in neuem Tab)Definiert Systemgrenze, Nutzer und Nachbarsysteme in einer Kontextsicht.
- C4 – Container diagram (öffnet in neuem Tab)Beschreibt Anwendungen und Datenspeicher innerhalb der Systemgrenze.
- C4 – Component diagram (öffnet in neuem Tab)Erklärt die Struktur und Verantwortlichkeiten innerhalb eines Containers.