Welche Entscheidung legt fest, ob der Checkout auf die Rechnung wartet, und wie lautet sie im Shop?

Die Kommunikationsentscheidung: Der Shop arbeitet asynchron, das PDF folgt später. Sie bestimmt Antwortzeit, Fehlerverhalten und Zwischenstatus.

Der Shop soll Bezahlung per Rechnung und per Karte anbieten. Ist „Strategy-Pattern für Zahlarten im Zahlungsmodul“ eine Architekturentscheidung? Und die Umbenennung einer Variable darin?

Das Strategy-Pattern ja: Es prägt den Vertrag zwischen Bestellung und Zahlung und jede künftige Zahlart. Die Umbenennung nein: Sie wirkt nur an einer Stelle; das entscheidet das Team im Code.

Das Team will die Produktsuche ebenfalls in SQL halten, um nur eine Datenbank zu betreiben. Wäge ab.

Dafür spricht weniger Betriebsaufwand mit einer Technik. Dagegen sprechen schwächere Volltextabfragen über Beschreibungen und Kategorien. Die Entscheidung hängt davon ab, wie wichtig die Suchqualität als Qualitätsziel ist.

KonzeptKapitel I · Grundlagen · Baustein 4 von 7

Architekturentscheidung

Eine Architekturentscheidung beantwortet eine prägende Entwurfsfrage mit nachvollziehbaren Gründen. Sie hält auch die Folgen der gewählten Option sichtbar.

Von Michael Meierhoff · Meierhoff Systems

EntwurfsfrageEine Frage, die mehrere Teile betrifft.
OptionenMindestens zwei echte Alternativen.
TragweiteWas die Wahl später bindet.

Einordnung

Warum das wichtig ist

Entscheidungen mit großer Tragweite sind später teuer zu ändern. Ohne gemeinsame Begründung diskutiert das Team sie erneut oder trifft sie unbemerkt im Code. Wie du sie festhältst, zeigt der Baustein ADR.

Dieser Baustein erklärt, welche Entwurfsfragen architektonische Tragweite haben. Das ADR zeigt, wie du eine solche Entscheidung dokumentierst.

Auf einen Blick · Von der Frage zur festgehaltenen Entscheidung

Eine Frage wird mit Optionen und Kriterien bewertet; die Entscheidung samt Folgen wird als ADR festgehalten.

Shop-Beispiel · Zuordnung

Die Entscheidungslandkarte des Shops

Das Shop-Team hat fünf Entscheidungen getroffen, die weit über ein einzelnes Modul hinausreichen: vom Systemstil über Kommunikation und Datenhaltung bis zu Mustern, auf die sich mehrere Module verlassen.

So liest du das Bild

Entwurfsfrage Die Spalte Entwurfsfrage, etwa „Wartet der Checkout auf die Rechnung?“
Optionen Die Spalte Optionen, etwa „Modularer Monolith · Microservices“.
Tragweite Die Spalte Warum Tragweite: Auslieferung, Fehlerverhalten, Konsistenz und gemeinsame Übergänge.

Die Entscheidungslandkarte des Shops
Art	Entwurfsfrage	Optionen	Entscheidung im Shop	Warum Tragweite
Systemstil	Wie wird der Shop gebaut und ausgeliefert?	Modularer Monolith · Microservices	Modularer Monolith	Bestimmt Auslieferung, Betrieb und Teamzuschnitt.
Kommunikation	Wartet der Checkout auf die Rechnung?	synchron · asynchron	Asynchron: Das PDF folgt später.	Bestimmt Antwortzeit, Fehlerverhalten und Zwischenstatus.
Datenhaltung	Wo liegen Bestellungen, wo die Produktsuche?	SQL · NoSQL · Suchindex	SQL für Bestellungen, Suchindex für Produkte	Bestimmt Konsistenz, Abfragemöglichkeiten und Betrieb.
Architekturmuster	Teilen sich Bestellabwicklung und Kundenservice-Übersicht ein Modell?	ein Modell · CQRS	CQRS mit eigener Leseübersicht	Bringt zwei Modelle, Synchronisierung und verzögerte Anzeige.
Entwurfsmuster mit Breitenwirkung	Wie werden Bestellstatus und erlaubte Übergänge geregelt?	verstreute Abfragen · State-Pattern	State-Pattern im Bestellmodul	Zahlung, Versand und Rechnung verlassen sich auf dieselben Übergänge.

Jede Zeile bindet mehrere Module, Teams oder Qualitätsziele und ist später teuer zu ändern. Keine Architekturentscheidung ist dagegen, wie eine Variable heißt oder wie eine Methode innen arbeitet; das entscheidet das Team im Code.

Nutzen & Grenzen

Hilft, wenn

Eine Wahl bindet mehrere Bausteine, Teams oder Qualitätsziele und soll mit ihren Folgen nachvollziehbar bleiben.
Mehrere plausible Optionen erfüllen unterschiedliche Prioritäten und müssen anhand gemeinsamer Kriterien verglichen werden.

Grenzen

Nicht jede Wahl ist eine Architekturentscheidung: Umbenennungen oder Methodeninternes entscheidet das Team im Code, ohne eigenen Beschluss.
Eine Entscheidung gilt für ihren damaligen Kontext; ändern sich Ziele oder Last, prüfe die Architekturtreiber neu.
Eine Entscheidung bleibt Absicht, bis jemand ihre Folgen prüft; Fitness Functions machen automatisierbare Eigenschaften beobachtbar.

In der Praxis

Frage und Entscheidungsspielraum formulieren. Beschreibe die zu lösende Entwurfsfrage und benenne verbindliche Randbedingungen. Das Ergebnis lässt mindestens zwei tatsächlich umsetzbare Optionen zu.
Optionen nach Folgen vergleichen. Bewerte Nutzen, Aufwand, Risiko und betroffene Qualitätsziele mit denselben Maßstäben. Eine Trade-off-Analyse hält sichtbar, welche Zielkonflikte den Vergleich prägen.
Beschluss und Neubewertungspunkt festhalten. Benenne die gewählte Option, ihre Gründe und ein Ereignis, das eine erneute Prüfung auslöst. Ein Architecture Decision Record dokumentiert diese Informationen für spätere Leser.

Ausführliche Erklärung lesen

Eine Entscheidung wird architektonisch relevant, wenn ihre Folgen mehrere Bausteine, Teams oder Qualitätsziele berühren und eine Änderung spürbaren Aufwand erzeugt. Typisch sind Systemstil, Kommunikationsart, Datenhaltung und Muster, auf die sich mehrere Module verlassen; wie eine Variable heißt oder eine Methode innen arbeitet, gehört nicht dazu. Der Beschluss bestimmt, welche Option unter den aktuell geltenden Zielen verfolgt wird. Treiber und Constraints grenzen den Lösungsraum ein; eine Trade-off-Analyse vergleicht die konkurrierenden Folgen.

Die Entscheidung selbst ist die getroffene Wahl. Ein Architecture Decision Record dokumentiert später Frage, Kontext, erwogene Alternativen und Konsequenzen, damit die Wahl nachvollziehbar bleibt. Neue Erkenntnisse können eine Neubewertung auslösen. Dann wird die bestehende Entscheidung ersetzt oder angepasst; der dokumentierte Grund erspart es, ihn aus dem Code rekonstruieren zu müssen.

Selbst prüfen

Teste dich in drei Stufen

AblesenIm Bild nachsehen
Welche Entscheidung legt fest, ob der Checkout auf die Rechnung wartet, und wie lautet sie im Shop?
Lösung mit Begründung ansehen
Die Kommunikationsentscheidung: Der Shop arbeitet asynchron, das PDF folgt später. Sie bestimmt Antwortzeit, Fehlerverhalten und Zwischenstatus.
AnwendenAuf eine neue Lage übertragen
Der Shop soll Bezahlung per Rechnung und per Karte anbieten. Ist „Strategy-Pattern für Zahlarten im Zahlungsmodul“ eine Architekturentscheidung? Und die Umbenennung einer Variable darin?
Lösung mit Begründung ansehen
Das Strategy-Pattern ja: Es prägt den Vertrag zwischen Bestellung und Zahlung und jede künftige Zahlart. Die Umbenennung nein: Sie wirkt nur an einer Stelle; das entscheidet das Team im Code.
BewertenEine Alternative abwägen
Das Team will die Produktsuche ebenfalls in SQL halten, um nur eine Datenbank zu betreiben. Wäge ab.
Lösung mit Begründung ansehen
Dafür spricht weniger Betriebsaufwand mit einer Technik. Dagegen sprechen schwächere Volltextabfragen über Beschreibungen und Kategorien. Die Entscheidung hängt davon ab, wie wichtig die Suchqualität als Qualitätsziel ist.

Vertiefen

Diese Bausteine führen die Gedanken dieser Seite weiter.

Quellen

Weiter im Lernpfad

Als Nächstes in Grundlagen & Orientierung: Architektursichten.

7 Bausteine

Weiter mitArchitektursichten