MethodenanleitungArchitecture

C4 Model

Die Anleitung zur Methode: Voraussetzungen und Materialien klären, den gesamten Ablauf verstehen und Ergebnisse, Stolperfallen sowie Abbruchkriterien nachschlagen.

KomplexitätNiedrig

Zeit1-4 h

Teilnehmende1-5

FormatWorkshop + Async

ReifegradCanonical

C4 Model planen

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenKlarer Umfang

Stimmt Gegenstand, Grenze und Entscheidung ab, bevor ihr das Modell füllt.

Ein zu breiter oder gemischter Umfang erzeugt ein irreführendes Modell.

Vorher abschließenZugang zu relevanten Belegen

Bringt Quellen und Personen mit Prozesswissen ein; trennt Fakten von Annahmen.

Ungeprüfte Deutungen wirken sonst wie gesicherte Erkenntnis.

Vorbereitung

Was vor Start vorliegen muss

Materialien

Gemeinsame Arbeitsfläche, Quellenbelege und eine abgestimmte Entscheidungsfrage.

Personen / Rollen

Architektur oder technische Leitung, Entwicklung, Product-/Fachvertretung.

Vorabinfos

Sammle vorhandene Daten, Beispiele, Rahmenbedingungen und relevante Perspektiven.

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.

Kernfrage

Die eine Frage, die diese Methode beantwortet

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

Ablauf

Phasen mit Ziel, Durchführung, Ergebnis und Stolperfalle

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.

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

1
Frage
System, Zielgruppe und Frage wählen
Ziel
Diagrammauftrag
Voraussetzungen für diesen Schritt
- Systemgrenze, Gesprächsanlass, Zielgruppe
Durchführung
- Definiere genau eine System-of-interest-Grenze und notiere, welche Verständnisfrage die Diagramme beantworten.
Ergebnis
Diagrammauftrag
Diagrammauftrag
Qualitätscheck
Ist die Frage mit einer Architekturansicht beantwortbar?
Stolperfalle
Ein Diagramm soll gleichzeitig Überblick und Implementierungsdetail zeigen. Teile nach Zielgruppe und Zoomstufe auf.
Zeitlicher Rahmen: Zeitbedarf richtet sich nach Umfang und Beleglage; es gibt keine allgemeine Dauer.
2
Kontext
System Context darstellen
Ziel
System-Context-Diagramm
Voraussetzungen für diesen Schritt
- Nutzer, Nachbarsysteme und belegte Beziehungen
Durchführung
- Zeichne das System als eine Box mit Nutzern und externen Systemen; beschrifte Beziehungen mit Zweck und Interaktion.
Ergebnis
System-Context-Diagramm
System-Context-Diagramm
Qualitätscheck
Sind externe Abhängigkeiten und Systemgrenze klar?
Stolperfalle
Interne Komponenten werden schon auf Context-Ebene gezeigt. Entferne Innenleben und erläutere System-of-interest separat.
Zeitlicher Rahmen: Zeitbedarf richtet sich nach Umfang und Beleglage; es gibt keine allgemeine Dauer.
3
Container
Container-Sicht ergänzen
Ziel
Container-Diagramm
Voraussetzungen für diesen Schritt
- Context-Sicht, ausführbare Deployables und Datenspeicher
Durchführung
- Zerlege das System in Anwendungen, Services und Datenspeicher; nenne Verantwortung, Technologie nur wenn hilfreich, und Verbindungen.
Ergebnis
Container-Diagramm
Container-Diagramm
Qualitätscheck
Sind Container deploybare oder ausführbare Einheiten?
Stolperfalle
„Container“ wird fälschlich als Docker-Container verstanden. Beschreibe den C4-Begriff und benenne die tatsächliche Softwareeinheit.
Zeitlicher Rahmen: Zeitbedarf richtet sich nach Umfang und Beleglage; es gibt keine allgemeine Dauer.
4
Details
Nur benötigte Zoomstufen pflegen
Ziel
Kohärenter Satz C4-Sichten
Voraussetzungen für diesen Schritt
- Offene Architekturfrage, Diagrammkonventionen und Owner
Durchführung
- Ergänze Component-, Code-, Dynamic- oder Deployment-Diagramm nur wenn es eine offene Frage klärt; kennzeichne Legende und Pflegeverantwortung.
Ergebnis
Kohärenter Satz C4-Sichten
Kohärenter Satz C4-Sichten
Qualitätscheck
Sind Begriffe, Richtung und Detailgrad für Leser verständlich?
Stolperfalle
Alle vier Ebenen werden automatisch erstellt und veralten. Lösche Sichten ohne Kommunikationszweck und aktualisiere den Rest gemeinsam.
Zeitlicher Rahmen: Zeitbedarf richtet sich nach Umfang und Beleglage; es gibt keine allgemeine Dauer.

Artefakt

Was am Ende rauskommt

Skizze: so sieht das Artefakt aus

C4 Model · Zoom-in von Kontext bis CodeVier Ebenen vom Systemkontext bis zur Implementierung

Form

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.

Versionierung / Ownership

Notiere Umfang, Datum, Beteiligte, Quellenstand und Verantwortung. Halte geänderte Annahmen samt Änderungsgrund fest.

Tool-Alternativen

Gemeinsames Whiteboard oder Papiervorlage
Quellen, Aufzeichnungen oder Messdaten

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.

Für die Arbeitsschritte bereitstellen

Frage: System, Zielgruppe und Frage wählen

Systemgrenze, Gesprächsanlass, Zielgruppe

Kontext: System Context darstellen

Nutzer, Nachbarsysteme und belegte Beziehungen

Container: Container-Sicht ergänzen

Context-Sicht, ausführbare Deployables und Datenspeicher

Details: Nur benötigte Zoomstufen pflegen

Offene Architekturfrage, Diagrammkonventionen und Owner

C4-Sichten

System Context

System, Menschen und Nachbarsysteme mit Beziehungen darstellen.

...

Container

Anwendungen, Services und Datenspeicher der Systemgrenze zeigen.

...

Component

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

...

Code

Code-Ebene nur bei relevantem Detailbedarf nutzen.

...

Supporting diagrams

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

...

Das leere Dokument enthält ausschließlich Abschnittsimpulse.

C4 model: Diagrams

Frage: System, Zielgruppe und Frage wählen

Erwartetes Artefakt: Diagrammauftrag

Diagrammauftrag

Eintrag:

...

Ist die Frage mit einer Architekturansicht beantwortbar?

Kontext: System Context darstellen

Erwartetes Artefakt: System-Context-Diagramm

System-Context-Diagramm

Eintrag:

...

Sind externe Abhängigkeiten und Systemgrenze klar?

Container: Container-Sicht ergänzen

Erwartetes Artefakt: Container-Diagramm

Container-Diagramm

Eintrag:

...

Sind Container deploybare oder ausführbare Einheiten?

Details: Nur benötigte Zoomstufen pflegen

Erwartetes Artefakt: Kohärenter Satz C4-Sichten

Kohärenter Satz C4-Sichten

Eintrag:

...

Sind Begriffe, Richtung und Detailgrad für Leser verständlich?

Offene Fragen und nächste Schritte

...

Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/c4-model/run-sheet

Beispielausgabe

Konkret gefülltes Szenario, fiktives Beispiel

Fiktives Beispiel zur Orientierung. Die genannten Mengen und Zeiten beschreiben diesen Fall und sind keine allgemeine Vorgabe.

c4-model-beispiel.md

Konkret gefülltes Szenario, fiktives Beispiel

Stolperfallen

Symptome erkennen, gegensteuern

Kurzüberblick, vollständiger Text steht in der jeweiligen Phase im Ablauf

System, Zielgruppe und Frage wählenEin Diagramm soll gleichzeitig Überblick und Implementierungsdetail zeigen.In der Phase ansehen
System Context darstellenInterne Komponenten werden schon auf Context-Ebene gezeigt.In der Phase ansehen
Container-Sicht ergänzen„Container“ wird fälschlich als Docker-Container verstanden.In der Phase ansehen
Nur benötigte Zoomstufen pflegenAlle vier Ebenen werden automatisch erstellt und veralten.In der Phase ansehen

Abbruchkriterien

Wann du anhalten, Voraussetzungen klären oder einen anderen Ansatz wählen solltest

Stoppe, wenn Frage oder Umfang strittig sind; stimmt sie zuerst ab.

Stoppe bei fehlenden Kerndaten und notiere den Evidenzbedarf.

Stoppe, wenn Annahmen als beobachtete Fakten behandelt werden.

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.

Im Playbook ansehenArchitekturdokumentation aufbauenVon verstreutem Architekturwissen zu Views, Entscheidungen und kommunizierbarer Dokumentation.

Methodenanleitung durchgearbeitet?

Zum Steckbrief für Zweck, ähnliche Methoden und Quellen oder direkt zur nächsten Methode im Katalog.

Zum Steckbrief Weitere Methoden