Architecture Mapping Tool

C4 Model

Macht System, Container und Bausteine in abgestuften Sichten lesbar und erleichtert Architekturkommunikation.

Das C4 Model macht ein System über mehrere Auflösungsebenen lesbar, vom Kontext bis zum Code. Es eignet sich, wenn verschiedene Zielgruppen dieselbe Architektur aus unterschiedlichen Höhen verstehen sollen.

Kernfrage

Welche Diagramme helfen den jeweiligen Zielgruppen, die Softwarearchitektur zu verstehen?

C4 Model planen Methodenanleitung

Vergleich starten

Feedback gebenHilft dir diese Methode?

Teilnehmende: 1-5
Zeit: 1-4 h

Die Schritte bilden einen möglichen Arbeitsweg. Passe sie an Zweck und verfügbare Belege der Methode an.

Papierillustration zu C4 Model mit den zentralen Arbeitsschritten und einem sichtbaren Ergebnis.

Frage
System, Zielgruppe und Frage wählen
Definiere genau eine System-of-interest-Grenze und notiere, welche Verständnisfrage die Diagramme beantworten.
Kontext
System Context darstellen
Zeichne das System als eine Box mit Nutzern und externen Systemen; beschrifte Beziehungen mit Zweck und Interaktion.
Container
Container-Sicht ergänzen
Zerlege das System in Anwendungen, Services und Datenspeicher; nenne Verantwortung, Technologie nur wenn hilfreich, und Verbindungen.
Details
Nur benötigte Zoomstufen pflegen
Ergänze Component-, Code-, Dynamic- oder Deployment-Diagramm nur wenn es eine offene Frage klärt; kennzeichne Legende und Pflegeverantwortung.

Überarbeite das Ergebnis, wenn sich Belege, Kontext oder Wirkung ändern. Halte fest, was sich geändert hat und warum.

Geeignet, wenn

Geeignet für: „Architecture Communication“, „Onboarding“. Beteiligte können die nötigen Belege und Entscheidungen einbringen.

Ideal für

Architecture Communication
Onboarding
Design Reviews

Nicht gut für

Domain Discovery
Strategische Marktanalyse

Ergebnisse

C4-Diagrammsatz
System Context, Container und bei konkretem Bedarf weitere Zoomstufen.
Kohärenter Satz C4-Sichten
Das Artefakt hält Umfang, Datum, Beteiligte, Quellenstand und Verantwortung fest und dokumentiert geänderte Annahmen mit Änderungsgrund.

C4-Sichten

Fiktives Arbeitsbeispiel

Fiktiv, Kontextdiagramm für Praxisportal: Patient:in nutzt Web-App; Praxispersonal nutzt Verwaltungsoberfläche; Portal ruft Praxisverwaltung ab und sendet Bestätigungen über E-Mail-Dienst. Containerdiagramm darunter: Web-Frontend, Booking API, Termin-Datenbank. Beziehung beschriftet: API liest verfügbare Slots und fordert Reservierung an. Keine Component-Sicht, solange sie keine konkrete Frage beantwortet.

System Context

System, Menschen und Nachbarsysteme mit Beziehungen darstellen.

Patient:in → Praxisportal → Praxisverwaltung.

Container

Anwendungen, Services und Datenspeicher der Systemgrenze zeigen.

Web-App → Booking API → Termindatenbank.

Component

Innere Bausteine nur zur Klärung einer konkreten Frage zerlegen.

Buchungsservice prüft Verfügbarkeit und Reservierung.

Code

Code-Ebene nur bei relevantem Detailbedarf nutzen.

Kein Code-Diagramm ohne konkreten Leserbedarf.

Supporting diagrams

Dynamic, deployment oder landscape ergänzen, wenn die Kommunikation es verlangt.

Deployment-Sicht für Betriebsübergabe.

Der Beispieltext ist fiktiv; ersetze ihn durch belegte Projektinformationen.

C4 model: Diagrams

Erster Schritt

Definiere genau eine System-of-interest-Grenze und notiere, welche Verständnisfrage die Diagramme beantworten.

Zur Methodenanleitung

Davor sinnvoll

Architecture

arc42

Liefert den Systemkontext, den die C4-Sichten schrittweise verfeinern.

Wie geht es weiter?

Papierillustration mit zwei betrachteten Optionen, die zu einem Entscheidungsdokument mit markiertem Status und sichtbaren Konsequenzen führen.

Architecture

Architecture Decision Record

Begründet, warum eine Container- oder Komponentengrenze so gezogen wurde.

Domain Modeling

Context Map

Zoomt aus der Systemsicht in die fachlichen Bounded Contexts dahinter.

Vertiefung

Zweck

Funktionsweise

Zuerst wird der Systemkontext mit Menschen, Nachbarsystemen und Grenzen beschrieben. Danach werden Container, Components und bei Bedarf Code-Sicht ergänzend dargestellt. So bleibt die Architektur auf jeder Ebene anschlussfähig, ohne in einem einzigen Diagramm zu viel zu überladen.

Im Detail

Das C4 Model funktioniert, weil es dieselbe Architektur in abgestuften Auflösungen zeigt und dadurch verschiedene Zielgruppen ohne Diagrammüberladung abholt. Gute Anwendung hält die Abstraktion je Ebene diszipliniert und vermeidet Mischbilder aus Kontext, Container und Detail. Wirksam wird der Ansatz, wenn Beziehungen, Verantwortungen und Schnittstellen pro Sicht so klar werden, dass Verständnisfragen schneller gelöst und falsche Annahmen früher entdeckt werden.

Durchführung

Kläre vorab, welche Sicht für welches Gespräch gebraucht wird, damit ihr nicht aus Gewohnheit alles gleichzeitig zeichnet. Ein tragender Moment entsteht dort, wo eine Ebene nicht mehr reicht und bewusst zur nächsten gewechselt wird. Schließe mit einem kompakten Satz gepflegter Sichten und klaren Regeln, wann welche davon aktualisiert werden muss.

Die Methodenanleitung führt mit 4 Phasen, Zeitrahmen, 4 Stolperfallen und klaren Abbruchkriterien durch die Umsetzung.

Methodenanleitung öffnen

Deine Einschätzung

Hilft dir diese Methode für dein Vorhaben?

Mit deinem Feedback hilfst du, den Methodatlas weiterzuentwickeln.

Quellen und Themen

Themen

Architektur Kommunikation Visualisierung

Quellen

C4 model: Diagramsc4model.comc4model.com von Simon Brown; beschreibt die vier Abstraktionsebenen Context, Container, Component und Code.

In Playbooks

Architekturdokumentation aufbauenVon verstreutem Architekturwissen zu Views, Entscheidungen und kommunizierbarer Dokumentation.

Artefakt-Vorlagen

C4 Model: ArbeitsvorlageBereite Entscheidung, Quellenbelege und nächste Prüfung vor.

markdown

c4-model-working-template.md

Bereite Entscheidung, Quellenbelege und nächste Prüfung vor.

C4 Model: Arbeitsvorlage

Fragestellung

Noch zu klären

Gewünschtes Ergebnis

Noch zu klären

Rahmen

Methode durchführen Zeit: Siehe Zeitrahmen im Katalog; keine allgemeine Dauer.

Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.

Vorbereitung für diesen Umfang

Methodische Grundausstattung

Materialien: Gemeinsame Arbeitsfläche, Quellenbelege und eine abgestimmte Entscheidungsfrage.
Rollen: Architektur oder technische Leitung, Entwicklung, Product-/Fachvertretung.
Vorab-Infos: Sammle vorhandene Daten, Beispiele, Rahmenbedingungen und relevante Perspektiven.
Gesamter Zeitbedarf: 60–120 Min. für ein erstes Modell; Details und Review hängen vom Systemumfang ab.
Setup: Zuerst wird der Systemkontext mit Menschen, Nachbarsystemen und Grenzen beschrieben. Danach werden Container, Components und bei Bedarf Code-Sicht ergänzend dargestellt. So bleibt die Architektur auf jeder Ebene anschlussfähig, ohne in einem einzigen Diagramm zu viel zu überladen.