Wir bauen eine Sofware-Architektur | Zusammenfassung

Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren

In dieser Folge von Software-Architektur im Stream baut Eberhard Wolff live eine Software-Architektur. Das Beispiel ist ein System, das einem Fahrradladen bei Reparaturen hilft. Als Input dient ein grobes Backlog mit drei Rollen: Kunden, Shop-Mitarbeiterinnen und Fahrradmechanikerinnen.

Der erste Schritt ist nicht die Struktur

Aus dem Chat kommen Vorschläge: Anforderungen dokumentieren, Qualitätsszenarien formulieren, arc42 nutzen. Eberhard Wolff nimmt das Backlog als Input, den andere liefern, und würde ein arc42-Template nicht blind in Kapitelreihenfolge ausfüllen. Die Frage, ob das System in der Cloud oder auf einem lokalen Server läuft, ist für ihn keine Anforderung, sondern eine Architekturentscheidung, die aus Anforderungen wie Verfügbarkeit oder Datenschutz folgt. Er beginnt auch nicht mit Boxen und Pfeilen, sondern mit dem System-Kontextdiagramm.

Das Kontextdiagramm klärt Schnittstellen und Verantwortung

Das Kontextdiagramm zeigt die drei Nutzergruppen und die Nachbarsysteme. Im imaginären Gespräch mit dem Auftraggeber kommen heraus: ein bestehender Webshop mit User-Datenbank, an den sich das Reparatursystem als eigener Bereich der Webseite anhängt, ein Online-Payment-Service wie PayPal, die Kasse im Laden, E-Mail und vielleicht SMS zur Benachrichtigung. Das Rechnungswesen ergänzt ein Chat-Teilnehmer, Eberhard Wolff hatte es übersehen. Nebenbei fällt eine Entscheidung: Das Reparatursystem führt selbst Buch über Ersatzteile, ein Inventarsystem wird nicht integriert. Genau das macht das Diagramm wertvoll. Es zeigt, wofür das System verantwortlich ist und mit wem es reden muss. Der technische Kontext nach arc42 ergänzt Protokolle wie JWT-Token im Cookie und REST-Schnittstellen, bringt für Eberhard Wolff aber weniger neue Erkenntnis als der Business-Kontext.

Qualitätsszenarien machen das Wichtige messbar

Ein Backlog sagt nichts darüber, ob das System sicher oder skalierbar sein muss. Statt darauf zu warten, klärt die Architekt:in das selbst, entlang der Qualitätsmerkmale der ISO 25010. Der Auftraggeber nennt Benutzerfreundlichkeit als Kern: Wenn Kunden keine Reparatur beauftragen können, scheitert das System. Dazu kommt der Wunsch, später eine SaaS-Lösung anzubieten. Daraus entstehen Szenarien: 90 Prozent der Nutzer beauftragen eine Reparatur in zwei Minuten, Kunden bewerten das System mit 4 von 5 Punkten, neue Mitarbeiter bedienen es nach einer Stunde, der Shop betreibt es ohne IT-Experten. Das Szenario, dass sich ein Kunde in einer Minute registriert, ist nicht erfüllbar, weil die Registrierung im Webshop liegt. Das Kontextdiagramm schließt es aus. Für die Verfügbarkeit reichen im Shop 99 Prozent zwischen 9 und 18 Uhr mit Ausfällen bis 30 Minuten, im Web sollen es 99,9 Prozent zwischen 7 und 24 Uhr sein. Der Umbau zum SaaS-System soll nicht mehr als 20 Personentage kosten.

Szenarien sind Akzeptanzkriterien, keine Tests

Felix und Theo wenden im Chat ein, dass Perzentile nötig sind, nicht alle Nutzer technikaffin sind und Testkunden fehlen. Eberhard Wolff hält dagegen: Ein Szenario beschreibt, wann der Auftraggeber zufrieden ist. Es lässt sich im Live-System beobachten, muss aber nicht zwingend zu einem Test werden.

Fazit

Nach Kontextdiagramm und Qualitätsszenarien gibt es noch keine Lösung, aber ein besseres Bild: Benutzerfreundlichkeit ist zentral, ein Änderungsszenario Richtung SaaS steht im Raum, die Verfügbarkeitsanforderungen sind entspannt. Erst jetzt lohnt es sich, über Cloud oder On-Premise nachzudenken. Die Struktur der Lösung folgt in der nächsten Folge.

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.