Welches Modul ruft den Zahlungsanbieter direkt auf?

Das Modul Zahlung. Nur von dort führt ein Pfeil zum Zahlungsanbieter; Bestellung beauftragt die Zahlung, spricht aber nicht selbst mit dem Anbieter.

Der Shop verkauft künftig auch Gutscheine mit eigenem Preis. In welchem Modul landet diese Änderung zuerst?

Im Katalog, denn er verantwortet Produkte und Preise. Warenkorb und Bestellung lesen die Preise nur und bleiben in ihrer Struktur unverändert.

Das Team überlegt, dass Bestellung den Zahlungsanbieter direkt aufruft. Was spricht dagegen?

Dann läge Wissen über den Anbieter in Bestellung und in Zahlung. Ein Anbieterwechsel beträfe mehrere Module; heute kapselt Zahlung den Anbieter allein. Wie man solche Entscheidungen festhält, zeigt Architekturentscheidung.

KonzeptKapitel I · Grundlagen · Baustein 1 von 7

Softwarearchitektur

Softwarearchitektur ist die Grundstruktur eines Systems: seine wichtigen Bausteine, ihre Beziehungen und die Entscheidungen, warum es so aufgebaut ist. Sie bestimmt, wie gut sich das System ändern, betreiben und erweitern lässt.

Von Michael Meierhoff · Meierhoff Systems

BausteineTeile mit einer klaren Aufgabe.
BeziehungenWer wen aufruft oder kennt.
EntscheidungenWarum es so aufgebaut ist.

Einordnung

Warum das wichtig ist

Architektur ist das, was später teuer zu ändern ist: die grobe Aufteilung und die Grundsatzentscheidungen. Details innerhalb eines Moduls lassen sich meist leichter korrigieren. Wie du Entscheidungen begründest und Qualitätsziele festlegst, vertiefen eigene Bausteine.

Hier geht es um das große Bild. Wie du einzelne Fragen mit passenden Darstellungen beantwortest, zeigt Architektursichten.

Auf einen Blick · Architektur aus Bausteinen und Entscheidungen

Anforderungen treiben Entscheidungen, und diese formen die Struktur aus Bausteinen und ihren Beziehungen.

Shop-Beispiel · Bausteine und Beziehungen

Architektur des modularen Shops

Der Shop ist ein modularer Monolith: eine einzige Anwendung, intern in sieben Module geteilt – Katalog, Warenkorb, Bestellung, Zahlung, Lager, Versand und Rechnung. Der Zahlungsanbieter ist ein fremdes System außerhalb des Shops.

So liest du das Bild

Bausteine Die Kästen: sieben Module und der Zahlungsanbieter.
Beziehungen Die Pfeile, zum Beispiel Bestellung → Zahlung.
Entscheidungen Nur Zahlung spricht mit dem Zahlungsanbieter; alle Module laufen in einer Anwendung.

Bausteinsicht: Jeder Pfeil ist ein Aufruf von der Quelle zum Ziel; die Antwort läuft über denselben Aufruf zurück. Weitere Aufrufe zwischen den Modulen sind nicht vorgesehen. Bestellung koordiniert Zahlung, Lager, Versand und Rechnung. Weitere Akteure zeigt der Systemkontext.

Nutzen & Grenzen

Hilft, wenn

Mehrere Personen arbeiten am selben System und müssen sich über Zuständigkeiten und Abhängigkeiten abstimmen.
Eine Änderung, etwa ein neuer Zahlungsanbieter, betrifft mehrere Module oder Qualitätsziele wie Sicherheit und Änderbarkeit.

Grenzen

Architektur legt Grenzen und Beziehungen fest, nicht die Programmierung jeder Funktion; Variablennamen entscheidet das Team im Code.
Die Beschreibung veraltet, wenn der Code abweicht. Vergleiche sie regelmäßig mit den Modulgrenzen und dem Laufzeitverhalten.
Eine einzelne Darstellung zeigt nur einen Ausschnitt; für andere Fragen braucht es weitere Architektursichten.

In der Praxis

Betrachtungsrahmen erkennen. Lies vorhandene Beschreibungen und benenne, welches System oder welcher Ausschnitt betrachtet wird und welche Verantwortung im Mittelpunkt steht. Für die formale Ausarbeitung von Nutzern und Nachbarn verweist Systemkontext & Systemgrenze.
Tragende Teile und Beziehungen ordnen. Beschreibe Verantwortungen und die erlaubten Übergänge zwischen ihnen. Verknüpfe die Sicht bei Bedarf mit Systemkontext & Systemgrenze, damit interne Zuständigkeiten und externe Abhängigkeiten unterscheidbar bleiben.
Vorhandene Strukturwahl und Wirkung erkennen. Halte fest, welche Abgrenzungen und Beziehungen bereits gelten und welche Weiterentwicklung sie beeinflussen. Optionenvergleich und Beschluss gehören zur Architekturentscheidung.

Ausführliche Erklärung lesen

Im Shop übernimmt jedes Modul eine Aufgabe: Katalog kennt Produkte und Preise, Zahlung kümmert sich ums Bezahlen. Architektur beschreibt, wo die Grenzen zwischen diesen Teilen liegen, wer wen aufruft und warum es so entschieden wurde. Sie betrifft den Aufbau (Struktur) und das Zusammenspiel zur Laufzeit.

Architekturentscheidungen verbinden eine gewählte Struktur mit ihren Gründen und erwarteten Folgen. Eine Beschreibung bleibt verständlich, wenn sie ihren Betrachtungsrahmen nennt und die passende Perspektive verwendet. Systemkontext & Systemgrenze klärt den Umfang; Architektursichten wählen die Perspektive für eine konkrete Frage.

ISO/IEC/IEEE 42010 beschreibt, was eine Architekturbeschreibung enthält: Beteiligte, ihre Anliegen, Sichten und die Begründung der Entscheidungen.

Selbst prüfen

Teste dich in drei Stufen

AblesenIm Bild nachsehen
Welches Modul ruft den Zahlungsanbieter direkt auf?
Lösung mit Begründung ansehen
Das Modul Zahlung. Nur von dort führt ein Pfeil zum Zahlungsanbieter; Bestellung beauftragt die Zahlung, spricht aber nicht selbst mit dem Anbieter.
AnwendenAuf eine neue Lage übertragen
Der Shop verkauft künftig auch Gutscheine mit eigenem Preis. In welchem Modul landet diese Änderung zuerst?
Lösung mit Begründung ansehen
Im Katalog, denn er verantwortet Produkte und Preise. Warenkorb und Bestellung lesen die Preise nur und bleiben in ihrer Struktur unverändert.
BewertenEine Alternative abwägen
Das Team überlegt, dass Bestellung den Zahlungsanbieter direkt aufruft. Was spricht dagegen?
Lösung mit Begründung ansehen
Dann läge Wissen über den Anbieter in Bestellung und in Zahlung. Ein Anbieterwechsel beträfe mehrere Module; heute kapselt Zahlung den Anbieter allein. Wie man solche Entscheidungen festhält, zeigt Architekturentscheidung.

Vertiefen

Diese Bausteine führen die Gedanken dieser Seite weiter.

Quellen

Weiter im Lernpfad

Als Nächstes in Grundlagen & Orientierung: Systemkontext & Systemgrenze.

7 Bausteine

Weiter mitSystemkontext & Systemgrenze