arc42 vs. C4-Modell: Unterschiede und wie man beide kombiniert

Jemand im Team schlägt arc42 für die Architekturdokumentation vor. Jemand anderes sagt, das Team nutze doch schon C4. Die anschließende Diskussion geht meist davon aus, dass man sich für eines entscheiden muss, und genau diese Annahme sollte man als Erstes über Bord werfen.

arc42 mit C4 zu vergleichen ist ein bisschen so, als würde man die Gliederung eines Berichts mit den Grafiken vergleichen, die darin stehen. arc42 ist ein Template: zwölf Abschnitte, die Ihnen sagen, was Sie über eine Architektur dokumentieren sollten, von den Qualitätszielen bis zu den Risiken. C4 ist ein Modell und eine Notation: vier Ebenen von Diagrammen, die Ihnen sagen, wie Sie die Struktur eines Softwaresystems zeichnen. An einigen Stellen überschneiden sie sich, und sie lassen sich gut kombinieren. Dieser Leitfaden zeigt, was beide jeweils abdecken, was arc42 verlangt, das C4 nicht zeichnet, was C4 zu arc42 beiträgt, und ordnet Abschnitt für Abschnitt zu, welches C4-Diagramm wohin gehört.

Die Antwort in einem Satz

arc42 ist ein Template für Architekturdokumentation. Das C4-Modell ist eine Methode, Softwarearchitektur-Diagramme zu zeichnen. Die meisten Teams, die beides nutzen, setzen C4-Diagramme in arc42-Abschnitte ein.

Die FAQ von arc42 beschreibt die Beziehung genau so. Auf die Frage „What about arc42 and C4?" heißt es dort, das C4-Modell habe „viele Ähnlichkeiten mit einigen Abschnitten von arc42, lasse aber bestimmte Teile weg (z. B. Qualitätsanforderungen, Querschnittliche Konzepte, Risiken und einige andere)" (arc42 FAQ, B-17). Dieselbe FAQ führt Simon Browns C4-Modell unter den Alternativen zu arc42 auf (A-6). Das stimmt, wenn Sie nur Diagramme brauchen, und führt in die Irre, wenn Sie alles andere brauchen, was ein Dokument enthält.

Die zwölf arc42-Abschnitte

Bevor man etwas zuordnet, hilft es, die Abschnitte mit ihren genauen Nummern vor sich zu haben. Sie stammen aus der arc42-Dokumentation, Template-Version 9.0 (Juli 2025, laut Download-Seite):

Eines stellt arc42 ausdrücklich klar: Sie füllen nicht alles aus. Auf die Frage „Welche Teile sind unverzichtbar?" antwortet die FAQ mit „Bitte füllen Sie nicht alles aus. Dokumentieren Sie nur, was Ihre Stakeholder brauchen", weil alles, was Sie schreiben, „künftig potenziell Wartungsaufwand erfordert" (B-1). Dieser Rat ist für die Kombination weiter unten wichtig. Ein schlankes arc42-Dokument mit guten C4-Diagrammen in drei Abschnitten schlägt ein vollständiges, das niemand aktualisiert.

Was arc42 abdeckt und C4 nicht

C4 befasst sich mit Struktur und, über seine ergänzenden Diagramme, mit Laufzeit und Deployment. Zu den Teilen einer Architektur, die keine Kästen sind, sagt es nichts. In arc42-Begriffen haben diese Abschnitte überhaupt kein C4-Gegenstück:

• Abschnitt 1, Einführung und Ziele. Warum das System existiert, wem es wichtig ist und die drei bis fünf Qualitätsziele, die jede spätere Entscheidung prägen. Ein C4-Kontextdiagramm zeigt, wer das System nutzt. Es kann nicht ausdrücken, dass „ein Checkout muss in unter zwei Sekunden abgeschlossen sein" wichtiger ist als „die Admin-Oberfläche sieht gut aus".
• Abschnitt 2, Randbedingungen. „Muss auf der Kubernetes-Plattform des Unternehmens laufen", „muss in Java geschrieben sein", „Daten dürfen die EU nicht verlassen". Randbedingungen erklären Entscheidungen, die ein Diagramm nur abbildet.
• Abschnitt 4, Lösungsstrategie. Die Handvoll grundlegender Entscheidungen (zuerst ein Monolith, Event Sourcing für das Ledger, die Suchmaschine zukaufen) an einer Stelle zusammengefasst.
• Abschnitt 8, Querschnittliche Konzepte. Authentifizierung, Fehlerbehandlung, Logging, Persistenzmuster, Internationalisierung. Sie ziehen sich durch jeden Kasten, deshalb kann kein einzelner Kasten sie zeigen.
• Abschnitt 10, Qualitätsanforderungen. Konkrete Qualitätsszenarien: Stimulus, Reaktion, Messgröße.
• Abschnitt 11, Risiken und technische Schulden. Was Sie als fragil kennen und was Sie aufgeschoben haben.
• Abschnitt 12, Glossar. Die Begriffe, die das Fachgebiet verwendet, einmal definiert.

Das sind genau die Abschnitte, die die arc42-FAQ nennt, wenn sie sagt, C4 „lasse bestimmte Teile weg". Besteht Ihre Architekturdokumentation nur aus C4-Diagrammen, sind das die Fragen, die ein neuer Architekt oder ein Auditor nach der Lektüre noch hat.

Was C4 zu arc42 beiträgt

arc42 schreibt bewusst keine Notation vor. Abschnitt 5 verlangt eine „hierarchische Sammlung von Blackboxes und Whiteboxes", Abschnitt 3 schlägt „alle Arten von Diagrammen, die das System als Blackbox zeigen" vor, und Abschnitt 6 akzeptiert alles von einer nummerierten Schrittliste bis zu Sequenzdiagrammen, BPMN oder Zustandsautomaten (Abschnitt 5, Abschnitt 3, Abschnitt 6). Diese Flexibilität ist eine Stärke des Templates, und sie ist zugleich die Stelle, an der sich arc42-Dokumente am stärksten unterscheiden: Jeder Autor zeichnet anders.

C4 schließt diese Lücke mit zwei Dingen:

1. Ein einheitlicher Zoom. Die Bausteinsicht von arc42 hat bereits Ebenen: Ebene 1 ist „die Whitebox-Beschreibung des Gesamtsystems zusammen mit Blackbox-Beschreibungen aller enthaltenen Bausteine", und Ebene 2 „zoomt in einige Bausteine der Ebene 1 hinein" (Abschnitt 5). Die C4-Ebenen geben diesen Zoomstufen eine feste Bedeutung (System, Container, Component, Code), sodass jemand, der C4 kennt, weiß, was er vor sich hat, bevor er die Beschriftungen liest.
2. Ein kleines gemeinsames Vokabular. Person, Softwaresystem, Container, Component, Beziehung, jeweils mit Namen, Beschreibung und meist einer Technologie. Das ist genug Notation, um Diagramme teamübergreifend vergleichbar zu machen, und wenig genug, dass niemand eine Schulung braucht.

Dazu kommt ein praktischer Vorteil. Stammen die C4-Diagramme aus einem Modell statt aus einem Zeichenwerkzeug, erscheint dasselbe Element mit demselben Namen in den Abschnitten 3, 5, 6 und 7. arc42 macht keine Vorgabe, wie Sie das erreichen, aber genau das sorgt dafür, dass die Abschnitte zueinander passen.

Zuordnungstabelle: welches C4-Diagramm in welchen arc42-Abschnitt gehört

Diese Zuordnung ist unsere eigene, abgeleitet aus den Abschnittsdefinitionen von arc42 und den Diagrammdefinitionen von C4. Die arc42-FAQ verweist auf Community-Beispiele für die Kombination (etwa bitsmugglers Beispiel-Repository für arc42 + C4), statt eine vorzuschreiben, und Teams unterscheiden sich in den Details, die in der letzten Spalte stehen.

Die Abschnitte, die nicht in der Tabelle stehen (1, 2, 4, 8, 10, 11, 12), bestehen aus Text und Tabellen, nicht aus C4-Diagrammen. Das ist keine Lücke in einer der beiden Methoden, sondern Arbeitsteilung.

Ein durchgearbeitetes Beispiel

So sieht die Kombination für das E-Commerce-System aus unserem vollständigen Leitfaden zum C4-Modell aus: eine React-Single-Page-App, ein API-Gateway, Go-Services für Bestellungen, Produkte und Benutzer, PostgreSQL-Datenbanken, Kafka und ein Benachrichtigungsservice. Es ist ein schlankes arc42-Gerüst mit platzierten C4-Diagrammen, kein vollständiges Dokument.

1. Einführung und Ziele
   - Zweck: Kunden stöbern im Sortiment und bestellen Produkte; Lagerpersonal verwaltet den Bestand
   - Qualitätsziele: (1) Checkout ist bei p95 in unter 2 s abgeschlossen
                     (2) keine Bestellung wird ohne erfolgreiche Zahlungsautorisierung bestätigt
                     (3) ein neuer Service kann ohne Änderung bestehender Services hinzugefügt werden

2. Randbedingungen
   - Läuft auf der Kubernetes-Plattform des Unternehmens; Go für Backend-Services

3. Kontextabgrenzung
   - Fachlicher Kontext: C4-System-Context-Diagramm
     [Kunde], [Lagerpersonal] -> [E-Commerce-Plattform]
     -> [Stripe], [FedEx API], [SendGrid]
   - Technischer Kontext: Tabelle Partner / Protokoll / ausgetauschte Daten

4. Lösungsstrategie
   - Datenbank pro Service; asynchrone Benachrichtigungen über Kafka

5. Bausteinsicht
   - Ebene 1: C4-Container-Diagramm (SPA, API Gateway, Order/Product/User
     Services, drei PostgreSQL-Datenbanken, Kafka, Notification Service)
   - Ebene 2: C4-Komponentendiagramm nur für den Order Service
     (Order Handler, Order Service, Order Repository, Payment Client,
     Inventory Client)

6. Laufzeitsicht
   - "Kunde gibt eine Bestellung auf": dynamisches C4-Diagramm, 10 nummerierte Schritte

7. Verteilungssicht
   - Produktion: C4-Deployment-Diagramm
   - Staging: nur Abweichungen von Produktion

8. Querschnittliche Konzepte
   - Authentifizierung am Gateway; Idempotenzschlüssel für POST /orders;
     strukturiertes Logging mit Request-ID

9. Architekturentscheidungen
   - ADR-001 Datenbank pro Service
   - ADR-002 Kafka für Bestell-Events statt synchroner Aufrufe
   - ADR-003 Zahlung autorisieren, bevor die Bestellung geschrieben wird

10. Qualitätsanforderungen
   - Szenario: 500 Checkouts pro Minute während eines Sales, p95 unter 2 s

11. Risiken und technische Schulden
   - Bestand wird vor der Zahlung reserviert; noch keine Kompensation bei fehlgeschlagener Zahlung

12. Glossar
   - Bestellung, Reservierung, Autorisierung, Fulfilment

Achten Sie darauf, wo die Diagramme stehen: in den Abschnitten 3, 5, 6 und 7. Alles andere sind ein paar Zeilen Text. Achten Sie auch darauf, wie sich das Risiko in Abschnitt 11 und ADR-003 in Abschnitt 9 auf dasselbe beziehen, was das dynamische Diagramm in Abschnitt 6 zeigt. In diesen Querverweisen zahlt sich ein kombiniertes arc42- und C4-Dokument aus: Das Diagramm zeigt die Reihenfolge der Schritte, der ADR sagt, warum, und das Risiko sagt, was noch nicht stimmt.

Für das dynamische Diagramm selbst geht der Leitfaden zum dynamischen C4-Diagramm genau dieses Szenario Schritt für Schritt durch. Für Abschnitt 9 behandelt der vollständige Leitfaden zu Architecture Decision Records das Format, das arc42 empfiehlt, und wie man einen Index pflegt.

Wenn Ihnen die zwölf Abschnitte von arc42 mehr erscheinen, als Ihr Team braucht, ist unser Template für Softwarearchitektur-Dokumentation eine kürzere Markdown-Gliederung auf Basis derselben Ideen, mit einem Abschnitt, der erklärt, wie sie sich auf arc42 zurückführen lässt.

Beides aktuell halten

arc42 und C4 teilen eine Schwachstelle: Beide sind hervorragend an dem Tag, an dem sie geschrieben werden. Die arc42-FAQ warnt selbst, dass jeder Abschnitt, den Sie ausfüllen, Wartung ist, zu der Sie sich verpflichtet haben (B-1). Einige Gewohnheiten, die sich bewähren:

• Halten Sie Diagramme aus dem Dokumenttext heraus, wo es geht. Referenzieren oder betten Sie Diagramme ein, die aus einem Modell erzeugt werden, statt Screenshots einzufügen. Ein Screenshot eines Container-Diagramms ist an dem Tag veraltet, an dem ein Container umbenannt wird. Ein aus dem Modell gerendertes Diagramm ist nur so veraltet wie das Modell.
• Legen Sie die schnell veränderlichen Abschnitte neben den Code. Die Abschnitte 5, 6 und 9 ändern sich mit dem Code. Die Abschnitte 1, 2 und 10 ändern sich mit dem Geschäft. Liegt die erste Gruppe im Repository (arc42 liefert dafür Markdown- und AsciiDoc-Templates), können Pull Requests sie aktualisieren.
• Schreiben Sie ADRs fort, bearbeiten Sie sie nie. Eine abgelöste Entscheidung bekommt einen neuen ADR. Abschnitt 9 wird so zu einer Historie statt zu einer umgeschriebenen Geschichte.
• Geben Sie jedem Abschnitt einen Owner und ein Review-Datum. Ein Dokument ohne Owner ist ein Dokument, das niemand aktualisiert.
• Prüfen Sie die strukturellen Abschnitte gegen den Code. Die Abschnitte 3 und 5 beschreiben Dinge, die im Code existieren, und lassen sich daher automatisch prüfen. Die Abschnitte 1, 8 und 10 nicht; sie brauchen ein menschliches Review, nach Plan.

Beim letzten Punkt kommt archyl ins Spiel, und nur für einen Teil des Problems. archyl hält das C4-Modell, kein arc42-Dokument. Seine KI-Erkennung schlägt aus einem Repository Systeme, Container, Komponenten und Beziehungen vor, die Sie freigeben, ADRs hängen an den C4-Elementen, die sie betreffen, und ein Drift-Score prüft, ob die dokumentierten Elemente noch im Code existieren. Das deckt die diagrammlastigen Abschnitte ab (3, 5, 6, 9). Ihre Qualitätsziele, Ihre querschnittlichen Konzepte oder Ihre Risikoliste schreibt es nicht, und es gibt keinen arc42-Export; die Textabschnitte bleiben in Ihrem arc42-Dokument und verlinken auf das Modell.

FAQ

Ist arc42 besser als C4?

Keines ist besser, weil sie nicht dieselbe Aufgabe erfüllen. arc42 ist ein Dokumentations-Template, das Ziele, Randbedingungen, Struktur, Laufzeit, Verteilung, Entscheidungen, Qualität und Risiken abdeckt. C4 ist eine Methode, Struktur einheitlich zu zeichnen. Brauchen Sie ein vollständiges Architekturdokument, nehmen Sie arc42 (oder etwas Vergleichbares). Brauchen Sie einheitliche Diagramme, nehmen Sie C4. Die meisten Teams, die beides brauchen, verwenden C4-Diagramme innerhalb von arc42.

Kann man arc42 und C4 zusammen verwenden?

Ja, und das ist verbreitet. arc42 schreibt keine Notation vor, deshalb passen C4-Diagramme direkt in seine Abschnitte: das Kontextdiagramm in Abschnitt 3, Container- und Komponentendiagramme in Abschnitt 5, dynamische Diagramme in Abschnitt 6 und Deployment-Diagramme in Abschnitt 7.

Wohin gehört das C4-Container-Diagramm in arc42?

In Abschnitt 5, Bausteinsicht, auf Ebene 1: die Whitebox-Sicht des Gesamtsystems. Komponentendiagramme gehören auf Ebene 2, für die Container, die sie brauchen. Ist Ihr System ein modularer Monolith, sind Ihre Bausteine auf Ebene 1 womöglich Module statt Container, und die Zuordnung ist lockerer.

Setzt arc42 UML voraus?

Nein. arc42 schlägt in mehreren Abschnitten Notationen vor (Abschnitt 3 erwähnt zum Beispiel ein UML-Verteilungsdiagramm für den technischen Kontext), überlässt die Wahl aber Ihnen. C4, UML und einfache Kästen und Pfeile werden alle damit verwendet.

Wohin gehören ADRs in arc42?

In Abschnitt 9, Architekturentscheidungen. arc42 selbst empfiehlt einen ADR für jede wichtige Entscheidung, in der Struktur von Michael Nygard, und erlaubt, eine Entscheidung lokal im betroffenen Baustein zu dokumentieren, wenn sich das besser liest.

Ist arc42 kostenlos?

Ja. Das Template ist kostenlos und Open Source, lizenziert unter CC BY-SA 4.0, und in zwölf Sprachen und Formaten verfügbar, darunter AsciiDoc, Markdown, Word und Confluence (Download-Seite).

Soll die C4-Hälfte Ihres arc42-Dokuments mit dem Code übereinstimmen? Testen Sie archyl kostenlos und erzeugen Sie das Modell aus Ihrem Repository. Weiterlesen: Was ist das C4-Modell? Ein vollständiger Leitfaden | Architecture Decision Records: Der vollständige Leitfaden | Leitfaden zum dynamischen C4-Diagramm | Template für Softwarearchitektur-Dokumentation.