Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
In dieser Folge von Software-Architektur im Stream setzt Eberhard Wolff das Beispielprojekt aus der vorherigen Folge fort, ein System für einen Fahrradladen. Nach Qualitätsszenarien und System-Kontext geht es nun um die Struktur der Lösung, also um das, was viele als klassische Software-Architektur verstehen.
Qualitätsszenarien entstehen im Dialog
Zuerst greift Eberhard Wolff Feedback aus den YouTube-Kommentaren auf. Jonas Stegmaier fragte, wer nicht-funktionale Anforderungen definieren soll, wenn der Kunde keine messbaren Vorgaben macht. Die Antwort: Qualitätsszenarien sind eine Kollaboration. Die Architekt:in weiß, wie man ein Szenario messbar formuliert, der Kunde weiß, worauf es fachlich ankommt. Entscheidend ist die Fragetechnik. Wer fragt, ob das System zuverlässig sein soll, bekommt immer ein Ja. Wer fragt, was passiert, wenn das System eine Minute, eine Stunde oder nachts um zwei ausfällt, lernt etwas über die Domäne. So zeigt sich etwa, dass die Auskunft über den Preis bei der Abholung kritischer ist als die Annahme einer Reparatur.
Außerdem grenzt er Benutzerfreundlichkeit von Performance ab. Wie schnell Benutzer:innen eine Aufgabe mit der Software erfolgreich lösen können, hängt von der Benutzerfreundlichkeit ab und nicht von der Performance. Wer das eine durch das andere ersetzt, weil sich Performance mit klassischen Architekturmaßnahmen umsetzen lässt, verfehlt das eigentliche Ziel.
Fachliche statt technische Aufteilung
Für die Struktur wählt Eberhard Wolff bewusst eine fachliche Zerlegung. Eine technische Schichtung in UI, Logik und Persistenz hält er auf dieser groben Ebene nicht für hilfreich. Ausgehend von den Stories des Systems entstehen vier Module: Terminplanung, Reparatur durchführen, Bezahlung und Materialbeschaffung. Die Terminplanung kennt nur Termine, Reparatur durchführen kennt Defekte, Ersatzteile und das Reparaturprotokoll, die Bezahlung kennt nur noch einen Geldbetrag, die Materialbeschaffung kennt Bestellungen beim Großhändler.
Am Beispiel des Reparaturstatus zeigt er ein allgemeines Muster: Der Kunde will auf einer Webseite sehen, wann die Reparatur geplant ist und was bereits gemacht wurde. Diese Information liegt in zwei Modulen. Statt ein eigenes Modul für den Status zu bauen, lässt er beide Module ihren Teil der Seite beisteuern. Ein eigenes Modul wäre erst bei einer deutlich anderen Sicht mit eigener Logik sinnvoll, etwa für Statistiken.
Boxen und Pfeile brauchen eine Semantik
Aus dem Chat kommt die Frage, ob man die Terminplanung nicht einkaufen könnte. Eberhard Wolff ordnet den Begriff Supporting Domain aus Domain-Driven Design ein: Eingekauft wird eine Generic Subdomain, und dabei akzeptiert man bewusst, dass die Lösung nur ungefähr passt. Eine Supporting Domain ist zu speziell als dass man sie einkaufen könnte.
Für das Diagramm legt er fest, was die Boxen bedeuten: Jedes Modul ist ein eigenes Projekt in der Versionskontrolle. Die Pfeile deutet er nach einer Chat-Frage als Richtung des Informationsflusses, damit Messaging nicht ausgeschlossen ist. Wichtig ist ihm die Build-Reihenfolge: Bezahlung und Materialbeschaffung müssen ohne die anderen Module gebaut werden können. Zum Schluss verbindet er die externen Systeme: SMS- und E-Mail-Versand sowie das Rechnungswesen hängen an Reparatur durchführen, Kasse und Online-Payment an der Bezahlung, und der Webshop bindet Seiten aus drei Modulen ein.
Fazit
Die Struktur des Systems folgt der Fachlichkeit, nicht der Technik. Vier Module mit klar getrennten Domänenmodellen bilden die nächste Ebene unter dem Kontextdiagramm aus arc42. Und Architektur-Diagramme, deren Boxen und Pfeile keine definierte Bedeutung haben, sagen nichts aus. Die Benutzerfreundlichkeit als wichtigstes Qualitätsziel behandelt die nächste Folge der Reihe mit seiner Kollegin Aminata.
Weiterführend
Die Architektur aus dieser Folgenreihe ist als arc42-Dokumentation mit Architekturentscheidungen (ADRs) aufbereitet: https://llm-coding.github.io/fahrrad-reparatur-architektur/. Die Dokumentation wurde automatisch aus den Transkripten der Folgen 111 bis 113 erstellt und kann Fehler enthalten.