We stand with the people of Ukraine
Please assist humanitarian efforts for the Ukrainian people and those affected by the military invasion of Ukraine by supporting international aid organizations, including the International Committee of the Red Cross.
arc42 gibt praxisorientierte Antworten auf die folgenden zwei Fragen:
- Was sollen wir über unsere Architektur kommunizieren/dokumentieren?
- Wie sollen wir kommunizieren/dokumentieren?
Dazu haben wir ein einfaches Template mit 12 Kapiteln entwickelt, in denen Sie alles Wissenswerte über die Architektur unterbringen können. arc42 lässt sich einfach an Ihre spezifischen Bedürfnisse anpassen.
Grundlegende Anforderungen, insbesondere Qualitätsziele
Regelungen und externe Randbedingungen
Externe Systeme und Schnittstellen
Kernideen und Lösungsansätze
Aufbau des Quellcodes, Modularisierung (hierarchisch)
Wichtige Laufzeitszenarien
Hardware, Infrastruktur & Deployment
Querschnittsthemen, oft sehr technisch und detailliert
Wichtige Entscheidungen (nicht anderweitig beschrieben)
Qualitätsbaum, Qualitätsszenarien
Bekannte Probleme und Risiken
Wichtige und spezifische Begriffe ("gemeinsame Sprache")
Den Kern der Architekturdokumentation bilden die Kontextabgrenzung (Kap. 3), die drei Sichten (Bausteinsicht, Laufzeitsicht und Verteilungssicht - Kap. 5 - 7), sowie die querschnittlichen Konzepte (Kap. 8).
Die restlichen Kapitel runden die Dokumentation ab. Sie halten u.a. Ziele, wichtige Entscheidungen und Risiken fest. Ein abschließendes Glossar stellt sicher, dass alle über das Gleiche sprechen.
Wenn Sie mehr zu den Kapiteln wissen wollen, lesen Sie weiter oder lernen Sie noch mehr Details über die jeweiligen Links.
Mehr Details
1. Einführung und Ziele
Kurze Beschreibung und Extrakt der requirements, Die Top3 (bis maximal 5) Qualitätsziele für die Architektur, deren Erreichung für die wichtigsten Stakeholder kritisch ist. Eine Übersicht über die wichtigsten Stakeholder mit deren Erwartungen bezüglich der Architektur.
2. Randbedingungen
Alles, was das Team beim Design und der Implementierung der Architektur einschränkt. Diese Einschränkungen sind manchmal auch außerhalb eines Projekts in der gesamten Organisation gültig.
3. Kontextabgrenzung
Grenzt das System, an dem Sie arbeiten, von externen Kommunikationspartnern (Nachbarsystemen und Benutzern) ab. Spezifiziert die externen Schnittstellen aus Sicht des Business (immer) und aus Sicht der Technologie (optional)
4. Lösungsstrategie
Zusammenfassung der fundamentalen Entwurfsentscheidungen und Lösungsstrategien für die Gesamtarchitektur. Kann Technologieentscheidungen, Top-Level-Zerlegungsstrategie oder Ansätze zur Erreichung der wesentlichen Qualitätsziele beinhalten, bzw. relevante Organisationsentscheidungen.
5. Bausteinsicht
Statische Zerlegung des Systems. Die Abstraktion des Sourcecodes, dargestellt als Hierarchie von “White-Boxes” (die wiederum kleinere Black-Boxes beinhalten), bis zu einem angemessenen Detaillierungsgrad.
6. Laufzeitsicht
Das Verhalten der Bausteine in Form von dynamischen Szenarien, die die wichtigsten Prozesse oder Features abdecken, Interaktionen an kritischen externen Schnittstellen oder “interessante” interne Abläufe und kritische Ausnahme- oder Fehlerfälle.
7. Verteilungssicht
Technische Infrastruktur mit (echten oder virtuellen) Prozessoren, Systemtopologie, und die Abbildung der Software-Bausteine auf diese Infrastruktur.
8. Querschnittliche Konzepte
Übergreifende, generelle Prinzipien und Lösungsansätze, die in vielen Teilen der Architektur einheitlich benutzt werden (→ cross-cutting). Konzepte beziehen sich oft auf mehrere Bausteine. Hier findet man Themen wie Domänenmodelle, Architekturmuster und -stile, Regeln zur Nutzung bestimmter Technologiestacks, etc.
9. Architekturentscheidungen
Wichtige, teure oder kritische oder riskante Architekturentscheidungen, die zentrale Bedeutung für das Gesamtsystem haben, mit Begründungen für diese Entscheidungen.
10. Qualitätsanforderungen
Qualitätsanforderungen in Form von Szenarien, mit einem Qualitätsbaum für den Überblick. Die allerwichtigsten dieser Qualitätsanforderungen sollten schon im Kapitel 1.2. (Qualitätsziele) aufgeführt sein.
11. Risiken und technische Schulden
Bekannte Risiken und angehäufte technische Schulden. Welche potentiellen Probleme lauern im und um das System? Über welche Schwächen beklagen sich die Entwicklungsteams?
Icon von Flaticon.com
12. Glossar
Wichtige Domänenbegriffe und technische Begriffe, die Stakeholder kennen sollten, wenn sie über die Architektur des Systems diskutieren. Manchmal auch Übersetzungstabellen, wenn in einer mehrsprachigen Umgebung gearbeitet wird.
Weitere Informationen
So - jetzt kennen Sie die einzelnen Teile des Templates. Gerne können Sie noch weiterlesen:
Schauen Sie in unsere weiterführende Doku:
- Die ausführliche Dokumentation des Templates, geordnet nach den Sektionen des Templates. Inklusive über 100 Tipps zur Anwendung.
- FAQ - Häufig gestellte Fragen)
- Unsere (neue) Seite über unser Quality Model.
- Einige der von uns geschriebenen Bücher beschäftigen sich mit arc42, beispielsweise:
- arc42 in Aktion
- arc42 by Example, Vol. 1, arc42 anhand von sechs praktischen Beispielen erklärt
- arc42 by Example, Vol. 2, Beispiele aus den Bereichen Echtzeit- und Embedded