C4 und arc42: Wenn ein Architekturmodell wirklich weiterhilft
Ein brauchbares Architekturmodell beantwortet eine Frage für bestimmte Menschen. Das C4-Modell hilft, unterschiedliche Detailstufen der Softwarearchitektur darzustellen. arc42 bietet einen Rahmen, um weitere Informationen wie Abläufe, Qualitätsanforderungen und Entscheidungen festzuhalten. Ihr Nutzen entsteht dort, wo diese Informationen in der Arbeit gebraucht und überprüft werden.
Stell dir vor, eine neue Kollegin kommt in dein Team. Ihr betreibt eine Buchungsplattform. Zur Einführung öffnest du euer Architekturdiagramm: Dienste, Datenbanken, Schnittstellen, Queue-Namen und einige zentrale Klassen. Es steckt viel Arbeit darin. Die Verbindungen stimmen.
Die Kollegin schaut auf die Übersicht und fragt: „Wo endet eigentlich unsere Verantwortung, wenn ein Kunde eine Buchung bestätigt?“
Du zoomst heraus. Die Beschriftungen werden kleiner.
Die Zeichnung enthält mehrere Gespräche gleichzeitig
Du weißt die Antwort. Die Plattform nimmt den Buchungswunsch entgegen; ein externes Reservierungssystem bestätigt die Verfügbarkeit. Eure Anwendung zeigt den Bearbeitungsstand an und verschickt später die Bestätigung.
Auf dem Diagramm ist all das enthalten. Zwischen internen Modulen, technischen Bibliotheken und Betriebsdetails verliert die einfache Beziehung aber ihre Kontur. Während du erklärst, springst du vom Kunden zur API, dann zur Queue, zum externen Anbieter und wieder zur Oberfläche. Die Kollegin versucht dabei herauszufinden, welche Kästchen zum selben System gehören.
Ihr beginnt eine zweite, kleinere Skizze. Darin stehen zunächst der Kunde, eure Buchungsplattform und das Reservierungssystem. Die Verbindungen bekommen eine Bedeutung: Buchung anfragen, Verfügbarkeit bestätigen, Status anzeigen. Damit lässt sich das erste Gespräch führen.
Die übrigen Details behalten ihren Wert. Sie warten auf eine andere Frage.
C4 macht die Detailstufe ausdrücklich
Genau für solche Perspektivwechsel gibt es die vier zentralen Sichten des C4-Modells: System Context, Container, Component und Code. Sie erlauben unterschiedlich tiefe Einblicke. Du wählst die Ebenen, die für deine Leser und ihre Fragen hilfreich sind.
Mit einer Kontextsicht könnt ihr klären, wer mit der Plattform arbeitet und welche externen Systeme beteiligt sind. Danach fragt die Kollegin, wo ein noch unbestätigter Buchungswunsch liegt. Jetzt wird der innere Aufbau relevant: Webanwendung, Backend, Worker und Datenspeicher.
Im C4-Sprachgebrauch ist ein Container eine Anwendung oder ein Datenspeicher. Der Begriff setzt keinen Docker-Container voraus. Die offizielle Erklärung des Container-Begriffs hilft gerade dann, wenn im Team bisher ausschließlich über Container als Betriebstechnik gesprochen wurde.
Für eure Buchung könnt ihr nun zeigen, dass das Backend den Wunsch speichert und ein Worker die weitere Verarbeitung übernimmt. Ein Blick in die inneren Komponenten des Workers wird erst nötig, wenn die Kollegin dort etwas ändern soll. Die Auswahl folgt ihrem Arbeitsauftrag.
Dabei lohnt es sich, den Namen jeder Verbindung laut auszusprechen. Ein Pfeil mit „nutzt“ kann vieles bedeuten. „Liest den Bearbeitungsstand“ oder „übermittelt eine Reservierungsanfrage“ macht die Beziehung im Beispiel besser prüfbar. Eine Darstellung wird schon dadurch hilfreicher, dass ihre Aussagen weniger Interpretationsspielraum lassen.
Eine Struktur erzählt noch keinen Ablauf
Die Kollegin kann den Aufbau jetzt erklären. Beim Testen bleibt eine Buchung jedoch länger auf „wird bearbeitet“. Sie möchte wissen, was in dieser Zeit passieren kann und wann der Support eingreifen muss.
Ihr geht einen konkreten Fall durch. Der Buchungswunsch ist gespeichert. Der Worker hat ihn abgeholt. Die Antwort des Reservierungssystems steht noch aus. Was sieht der Kunde? Wann wird erneut nachgesehen? Woran lässt sich ein ungewöhnlich langer Vorgang erkennen?
Diese Fragen verdienen eine Ablaufbeschreibung. Wenn ihr jede zeitliche Besonderheit in das Strukturbild einzeichnet, wird die gerade gewonnene Übersicht wieder schwer lesbar. Ihr haltet deshalb den Weg einer Buchung als eigenen Fall fest und verweist auf die beteiligten Bausteine.
arc42 bietet für solche Informationen einen Dokumentationsrahmen. Darin haben unter anderem Kontext, Bausteine, Laufzeitszenarien, Entscheidungen und Risiken unterschiedliche Aufgaben. C4-Sichten können in eine solche Dokumentation eingehen. Die beiden Ansätze helfen also bei verschiedenen, miteinander verbundenen Fragen.
Für eure Plattform bleibt außerdem eine Begründung wichtig: Warum wird die Reservierung im Hintergrund bearbeitet? Vielleicht muss die Oberfläche auch bei langsamen Antworten erreichbar bleiben. Diese Entscheidung lässt sich aus einem Worker-Kästchen allein nicht ablesen. Wie du solche Gründe knapp festhältst, zeigt der Artikel über Architekturentscheidungen und ADRs.
Das Modell bekommt einen Platz in der Arbeit
Bis hierhin habt ihr verständlichere Dokumentation. Ob daraus eine verlässliche Arbeitsgrundlage wird, zeigt die nächste Änderung.
Angenommen, die Bestätigung soll künftig über einen weiteren Anbieter möglich sein. Vor dem Umbau legt ihr die Kontextsicht daneben. Der neue Anbieter kommt hinzu. Im inneren Aufbau prüft ihr, wo seine Auswahl und Anbindung liegen. Am Ablauf besprecht ihr, wie ein Wechsel nach einem unklaren Ergebnis vermieden wird. Dieselbe Änderung erzeugt in jeder Sicht eine andere konkrete Frage.
Ihr müsst dafür keine zweite Version des gesamten Quellcodes pflegen. In der Dokumentation bleiben die Beziehungen und Entscheidungen, die das Gespräch tragen. Details können auf konkrete Konfigurationen, Schnittstellen oder Implementierungen verweisen. So ist erkennbar, wo die technische Wahrheit nachgeschlagen und überprüft werden kann.
Hilfreich ist eine klare Abmachung für Änderungen: Wer eine relevante Beziehung verändert, prüft auch die betroffene Sicht. Das funktioniert besser, wenn die Darstellung bei Planung und Review tatsächlich geöffnet wird. Eine Datei, die nur für seltene Präsentationen gebraucht wird, liefert wenig Anlass zur Pflege. Euer Arbeitsablauf muss ihr einen echten Zweck geben.
Die Kollegin kann selbst weitererklären
Das ist die Verbindung zu THINK FIRST Individual: Im Modul „Stabilität herstellen“ behandelt die Lektion „Ein Systemmodell wirklich nutzen und pflegen“, wie aus sichtbaren Zusammenhängen eine fortlaufend genutzte Arbeitsgrundlage wird. C4 und arc42 können diese Arbeit unterstützen. Der Kurs selbst ist keine Ausbildung in den beiden Ansätzen.
Zurück zur Kollegin. Beim nächsten Gespräch erklärt sie, an welcher Stelle eine Buchung auf das externe System wartet. Für die Frage nach der Zuständigkeit öffnet sie die Kontextsicht. Für die Änderung am Worker geht sie eine Ebene tiefer. Ihr könnt ihre Erklärung prüfen und dort ergänzen, wo etwas fehlt.
Das große Diagramm vom ersten Tag enthält vielleicht noch immer mehr Details. Die neue Dokumentation hilft euch inzwischen bei mehr Entscheidungen. Jede Sicht hat eine erkennbare Aufgabe – und jemand weiß, wann er sie braucht.