Key insights: Arc42 erklärt: Pragmatische Software-Architekturdokumentation in 12 Abschnitten

Was ist Arc42 und warum ist es im deutschsprachigen Raum Standard?

Arc42 ist ein pragmatisches Framework zur Software-Architekturdokumentation, entwickelt von Gernot Starke und Peter Hruschka. Es unterteilt Architekturdokumentation in 12 klar definierte Abschnitte und ist bewusst technologieneutral – es funktioniert für Java-Monolithen ebenso wie für Microservices oder eingebettete Systeme.

Im deutschsprachigen Raum hat sich Arc42 als De-facto-Standard etabliert, weil es agil-kompatibel ist: Teams füllen nur die Abschnitte aus, die für ihr Projekt relevant sind, und erweitern die Dokumentation iterativ. Das unterscheidet Arc42 von schwergewichtigen Enterprise-Frameworks.

Die 12 Arc42-Abschnitte im Überblick

Arc42 strukturiert Architekturdokumentation in diese Bereiche: 1. Einführung und Ziele (Anforderungen, Stakeholder), 2. Randbedingungen (technische und org. Constraints), 3. Kontextabgrenzung (Systemgrenzen und externe Schnittstellen), 4. Lösungsstrategie (zentrale Architekturentscheidungen), 5. Bausteinsicht (statische Struktur), 6. Laufzeitsicht (dynamisches Verhalten), 7. Verteilungssicht (Deployment-Topologie), 8. Querschnittliche Konzepte (Logging, Security etc.), 9. Entwurfsentscheidungen (ADRs), 10. Qualitätsanforderungen, 11. Risiken und technische Schulden, 12. Glossar.

Arc42 vs. andere Dokumentationsframeworks (C4, SAD)

Das C4-Modell (Simon Brown) fokussiert auf vier Diagrammebenen (Context, Container, Component, Code) und ist damit schlanker, aber weniger umfassend als Arc42. Es eignet sich gut als Ergänzung zu Arc42 für die Baustein- und Kontextsicht.

Klassische SADs (Software Architecture Documents) nach IEEE-Standard sind formaler und aufwändiger – Arc42 bietet einen guten Mittelweg zwischen agiler Leichtigkeit und dokumentierter Nachvollziehbarkeit, der für mittelständische Teams gut passt.

Arc42 einführen: Empfehlungen für den Einstieg

Fangen Sie nicht mit allen 12 Abschnitten an. Priorisieren Sie: Abschnitt 1 (Einführung und Ziele), Abschnitt 3 (Kontextabgrenzung), Abschnitt 5 (Bausteinsicht) und Abschnitt 9 (Entwurfsentscheidungen als ADRs) decken den größten Nutzen für das kleinste Aufwandsbudget ab. Die restlichen Abschnitte füllen Sie bei Bedarf.

Verwandte Themen: Clean Architecture vs. Domain-driven Design: Wann welcher Ansatz?, Software-Architektur-Review: Ablauf, Phasen und was Sie erwarten können. Zur Übersicht: Software-Architektur →