Das C4-Modell: Kontext, Container, Komponenten und Code

Landkarten Ihres Codes

Das C4-Modell ist ein Ansatz zur Darstellung von Softwarearchitektur in Diagrammen, den Simon Brown entwickelt hat. Es ist aus den Softwarearchitektur-Schulungen entstanden, die er ab etwa 2006 gab: Laut der C4-Website reichen seine Wurzeln in die Zeit zwischen 2006 und 2009 zurück, die Diagrammtypen erhielten Anfang 2010 ihre Namen, und der Name „C4“ wurde Anfang 2011 erstmals verwendet. Brown war aufgefallen, dass Teams, die ihre Architektur zeichnen sollten, schwer verständliche Diagramme lieferten: unerklärte Formen und Farben, Kästen, die alles von einer Klasse bis zu einem Rechenzentrum sein konnten, unbeschriftete Linien und mehrere Detailebenen auf einer Seite. UML, das das Problem hätte lösen können, war im Alltag weitgehend außer Gebrauch gekommen.

Seine Antwort war keine neue Notation, sondern eine kleine Menge von Abstraktionen und eine darauf aufbauende Hierarchie von Diagrammen, die er mit den Zoomstufen einer Online-Karte vergleicht. Sie beginnen mit dem ganzen Land, zoomen in eine Stadt, dann in einen Bezirk, dann in eine Straße. Jede Stufe zeigt für einen anderen Zweck unterschiedlich viele Details, und Sie wissen immer, welche Stufe Sie betrachten. C4 ist bewusst unabhängig von Notation und Werkzeug: Sie können es auf einem Whiteboard, in einem Zeichenwerkzeug oder mit einem Modellierungswerkzeug zeichnen, sofern Sie ein paar Regeln befolgen.

C4 ist zu einem der am weitesten verbreiteten Ansätze für Architekturdiagramme geworden, weil es leicht zu lernen ist, sich natürlich in das Denken in mehreren Sichten aus Abschnitt 4.2 einfügt und Diagramme hervorbringt, denen Entwicklungsteams wie fachfremde Leser folgen können. In der Begriffswelt von 42010 ist jeder C4-Diagrammtyp ein Blickwinkel mit eigener Modellart; C4 hält die Menge nur klein.

Die Abstraktionen: Personen, Softwaresysteme, Container, Komponenten

C4 baut auf vier Abstraktionen auf, dazu kommt der Code. Eine Person ist ein menschlicher Nutzer des Systems: ein Kunde, ein Kurier, eine Supportkraft. Ein Softwaresystem ist die höchste Abstraktionsebene, etwas, das seinen Nutzern einen Wert liefert und typischerweise von einem Team oder einer Organisation besessen und gebaut wird; die Essenslieferplattform ist eines, ebenso der Zahlungsanbieter und der Kartendienst, von denen sie abhängt.

Ein Container ist etwas, das laufen muss, damit das System funktioniert: nach Browns Worten im Wesentlichen eine Laufzeitgrenze um Code, der ausgeführt wird, oder um Daten, die gespeichert werden. Beispiele sind eine serverseitige Webanwendung, eine Single-Page-App im Browser, eine Mobile-App, eine Desktop-Anwendung, eine Serverless-Funktion, ein Datenbankschema, ein Dateispeicher oder ein Message-Topic. Jeder ist separat deploybar oder lauffähig, und Container kommunizieren über Prozessgrenzen hinweg miteinander, meist über ein Netzwerk.

Eine Komponente ist eine Gruppierung zusammengehöriger Funktionalität hinter einer klar definierten Schnittstelle; sie lebt innerhalb eines Containers und läuft im selben Prozess wie die anderen Komponenten dort. In einem Java-Service kann sie eine Menge von Klassen hinter einer Schnittstelle sein, in einem Node.js-Service ein Modul. Komponenten sind nicht separat deploybar; der Container ist die Deployment-Einheit. Schließlich ist Code die Klassen, Funktionen und Tabellen, die eine Komponente implementieren.

Ebene 1: das Systemkontextdiagramm

Das Systemkontextdiagramm ist der Ausgangspunkt. Es stellt das beschriebene System als einzelnen Kasten in die Mitte und umgibt es mit den Personen, die es nutzen, und den Softwaresystemen, von denen es abhängt oder die von ihm abhängen. Es verbirgt bewusst alle internen Details, einschließlich Technologien, Protokollen und interner Services. Es beantwortet die Fragen, die jeder Neuling, jedes Produktmanagement und jede Sicherheitsprüfung zuerst stellt: Was ist dieses System, wer nutzt es, und womit ist es verbunden?

Weil es das Innenleben verbirgt, ist das Kontextdiagramm auch das richtige Diagramm für Gespräche mit fachfremden Stakeholdern und für die Abgrenzung: Wo endet unsere Verantwortung? Im folgenden Essenslieferbeispiel zeigt es sofort, dass Kartenzahlungen, Routenplanung und Push-Zustellung zugekauft sind, was architekturrelevant ist (jedes davon ist eine externe Abhängigkeit mit eigener Verfügbarkeit, eigenen Kosten und eigenem Vertrag) und in den meisten Sichten auf Codeebene unsichtbar bleibt.

Ebene 2: das Containerdiagramm

Das Containerdiagramm zoomt in den Systemkasten und zeigt die Container darin: die Anwendungen und Datenspeicher, aus denen das System besteht, wofür jeder verantwortlich ist, welche Technologie jeder nutzt und wie sie kommunizieren. Für die meisten Teams ist das das wertvollste Diagramm, das sie besitzen. Es zeigt die wichtigsten Strukturentscheidungen (wie viele deploybare Einheiten, welche synchron und welche über Messaging kommunizieren, welche Daten besitzen) und ist konkret genug für Entwicklung und Betrieb, passt aber immer noch auf eine Seite.

Beachten Sie zwei Entscheidungen im folgenden Diagramm. Das Message-Topic für Bestellereignisse ist als eigener Container gezeichnet, weil es ein Speicher ist, in den Produzenten schreiben und aus dem Konsumenten lesen; die C4-Anleitung bietet diesen expliziten Stil an oder alternativ, das Topic wegzulassen und „über Topic für Bestellereignisse“ an die Pfeile zu schreiben. Das Zeichnen macht die Kopplung über das Topic deutlich sichtbar. Und die asynchronen Beziehungen verwenden eine gestrichelte Linie, die die Legende erklärt. Das Containerdiagramm sagt nichts darüber, wie viele Kopien jedes Service laufen, in welcher Region oder hinter welchem Load Balancer; das gehört in ein Deployment-Diagramm.

Ebene 3: das Komponentendiagramm

Das Komponentendiagramm zoomt in einen Container und zeigt die Komponenten darin. Es richtet sich an Architekten und Entwicklungsteams, die an diesem Container arbeiten, und hier wird die innere Struktur eines Service sichtbar: welcher Teil eingehende Anfragen bearbeitet, wo die Geschäftsregeln liegen, welcher Teil mit der Datenbank spricht, wie Ereignisse den Service verlassen.

Die C4-Anleitung empfiehlt, Komponentendiagramme nur dort zu zeichnen, wo sie einen Mehrwert bieten, typischerweise für Container, die komplex oder riskant sind oder von vielen Personen geändert werden, und sie automatisch zu generieren, wenn sie lange erhalten bleiben sollen, weil sich die Komponentenstruktur so oft ändert wie der Code. Bei der Essenslieferplattform erfüllt der Bestellservice diese Kriterien: Er verarbeitet Geld, spricht mit einem externen Anbieter und muss Ereignisse zuverlässig publizieren. Das folgende Diagramm zeigt eine typische Struktur, einschließlich einer Outbox-Komponente, die Ereignisse in derselben Transaktion wie die Bestellung in die Datenbank schreibt und sie anschließend an Kafka weiterleitet (das Outbox-Muster wird in Kapitel 6 behandelt).

Ebene 4: Code und die ergänzenden Diagramme

Die Codeebene zoomt in eine Komponente und zeigt ihre Klassen, Schnittstellen oder Tabellen, meist als UML-Klassendiagramm oder Entity-Relationship-Diagramm. Die C4-Anleitung behandelt sie als optional und hält es in der Regel nicht für lohnend, sie von Hand zu zeichnen: Die meisten Entwicklungsumgebungen können sie bei Bedarf generieren, und eine handgezeichnete Kopie ist veraltet, sobald jemand refaktoriert. Zeichnen Sie sie nur für die wichtigsten oder verwickeltsten Teile, etwa ein Domänenmodell im Herzen des Geschäfts (Abschnitt 4.4 zeigt ein solches Klassendiagramm).

Drei ergänzende Diagramme füllen die Lücken, die die Hierarchie lässt. Ein Systemlandschaftsdiagramm ist ein Kontextdiagramm ohne ein einzelnes System im Fokus: Es zeigt alle Softwaresysteme und Personen einer Organisation oder Domäne, was für Enterprise- und Plattformarchitekten nützlich ist. Ein dynamisches Diagramm zeigt, wie Elemente zur Laufzeit für ein Szenario zusammenarbeiten, als nummerierte Interaktionen auf einem Container- oder Komponentendiagramm (oder als UML-Sequenzdiagramm); das ist das C4-Gegenstück zu den Szenarien in 4+1. Ein Deployment-Diagramm zeigt, wie Container in einer Umgebung auf Infrastruktur abgebildet werden: Deployment-Knoten wie Cloud-Regionen, Kubernetes-Cluster, virtuelle Maschinen, Managed-Datenbankdienste und Geräte, mit der Anzahl der Instanzen. C4 empfiehlt ein Deployment-Diagramm je relevanter Umgebung, typischerweise Produktion und vielleicht Staging.

Notationsregeln, die Diagramme lesbar machen

C4 schreibt keine Formen oder Farben vor, wohl aber, was jedes Diagramm aussagen muss. Diese Regeln, verdichtet aus der C4-Notationsanleitung, machen die obigen Diagramme lesbar, ohne dass es eines Meetings zu ihrer Erklärung bedarf.

Werkzeuge: Zeichnen oder Modellieren

C4-Diagramme lassen sich mit jedem Zeichenwerkzeug erstellen, und viele Teams beginnen mit einem Whiteboard oder einer allgemeinen Diagrammanwendung. Die C4-Website unterscheidet zwei Familien von Werkzeugen. Zeichenwerkzeuge zeichnen Kästen und Linien; sie sind flexibel und vertraut, aber die Diagramme sind unabhängige Bilder, sodass das Umbenennen eines Elements bedeutet, jedes Diagramm zu bearbeiten, das es zeigt, und nichts prüft, ob die Diagramme übereinstimmen. Modellierungswerkzeuge halten ein einziges Modell aus Personen, Systemen, Containern, Komponenten und Beziehungen und erzeugen jedes Diagramm als Sicht auf dieses Modell; umbenannt wird einmal, die Diagramme bleiben konsistent, und das Modell lässt sich abfragen und validieren.

Structurizr, von Simon Brown entwickelt, ist das Referenz-Modellierungswerkzeug für C4. Seine textbasierte Structurizr DSL beschreibt das Modell und die Sichten in einer Datei, die neben dem Code in der Versionsverwaltung liegt. Weitere Optionen sind C4-PlantUML (C4-Formen für PlantUML), die C4-Diagrammunterstützung von Mermaid und verschiedene kommerzielle Modellierungswerkzeuge; Abschnitt 4.7, Diagrams as Code, zeigt Beispiele. Die Wahl ist weniger wichtig als die Gewohnheit: Halten Sie die Quelle der Diagramme dort, wo das Team arbeitet, und aktualisieren Sie sie im selben Pull Request wie die Änderung, die sie beschreibt.