Laufzeitsicht

Die Szenarien in diesem Kapitel sind aus den Pfeilen der Bausteinsicht (Board Seite 9) und dem technischen Kontext (Board Seite 3) abgeleitet. Eberhard Wolff beschreibt in den Videos keinen Ablauf Schritt für Schritt. Wo ein Schritt über die Pfeile hinausgeht, stützt er sich auf ein ADR; wo weder Board noch ADR etwas hergeben, steht eine offene Notiz. Die Reihenfolge der Aufrufe innerhalb eines Szenarios ist eine Lesart, keine Aussage des Boards. Die Pfeile auf dem Board bedeuten Informationsfluss, nicht Aufrufrichtung (Folge 112, 58:17); die Sequenzdiagramme zeigen deshalb eine mögliche Aufrufreihenfolge, keine festgelegte.

Jeder Baustein aus Kapitel 5 kommt in mindestens einem Szenario vor: Terminplanung in Szenario 1, Reparatur durchführen und Materialbeschaffung in Szenario 2, Bezahlung in Szenario 2 und 4. Das fünfte Szenario, der Netzausfall im Laden, betrifft alle Bausteine gleich und kommt ohne Diagramm aus.

Reparatur online beauftragen

Kund:innen beauftragen eine Reparatur über den Webshop. Der Login läuft über den Webshop (ADR-001), das Reparatur-System liegt unter /reparatur derselben Domain, damit das JWT-Cookie mitkommt (ADR-002).

06 online beauftragen
Schritte

  1. Kund:in meldet sich im Webshop an. Der Webshop prüft das Konto in der Webshop User Database und stellt ein JWT als Cookie aus (ADR-001).

  2. Kund:in ruft /reparatur auf. Der Browser sendet das JWT-Cookie mit, weil Domain und Origin gleich bleiben (ADR-002).

  3. Der Webshop leitet /reparatur an das Reparatur-System um. Auf dem Board endet der Pfeil bei Terminplanung, Reparatur durchführen und Bezahlung; für die Anmeldung ist Terminplanung der Einstieg.

  4. Terminplanung liest das JWT und holt Adresse und Zahlungsart über die REST-Schnittstelle des Webshops (ADR-001).

  5. Terminplanung zeigt das Auftragsformular, vorbelegt mit den Daten aus dem Webshop.

  6. Kund:in trägt Fahrrad und Problem ein und sendet ab (Story "Fahrrad zur Reparatur anmelden").

  7. Terminplanung berechnet den Termin (Story "Reparaturtermin berechnen") und gibt "Termin" an Reparatur durchführen (Board Seite 9).

  8. Kund:in sieht die Bestätigung mit dem Termin.

Besonderheiten

Der Webshop hält keine Reparaturdaten. Den Status sieht die Kund:in später auf einer Seite, die das Reparatur-System selbst rendert (ADR-005). Das Usability-Ziel aus Kapitel 10 gilt für diesen Ablauf: 90 % der Benutzer:innen beauftragen eine Reparatur in zwei Minuten (Board Seite 5).

Note
 Offen: Ob Schritt 4 (Adressabfrage) in Terminplanung oder in einem gemeinsamen Teil des Systems liegt, sagt das Board nicht. Das Format des Aufrufs "Termin" ist nicht festgelegt. Ob die Module sich synchron aufrufen oder Messages austauschen, hat Eberhard in Folge 112 ausdrücklich offen gelassen: "auf dieser Ebene noch nicht" (57:01, ADR-012).

Reparatur durchführen, abrechnen, bezahlen

Die Werkstatt führt die Reparatur aus, das System rechnet ab und die Kund:in bezahlt bei der Abholung. Das Szenario verbindet vier Bausteine und vier externe Systeme. Die Bezahlung folgt ADR-004, die Benachrichtigung ADR-007.

06 durchfuehren bezahlen
Schritte

  1. Shop-Mitarbeiter:in nimmt das Fahrrad an (Story "Fahrrad zur Reparatur abgeben").

  2. Mechaniker:in nimmt den Defekt auf: "Schaltung kaputt" (Board Seite 7). Reparatur durchführen berechnet die voraussichtlichen Kosten.

  3. Mechaniker:in protokolliert jede Position mit Dauer und Preis. Beispiel vom Board: neues Schaltwerk gekauft 100 €; altes Schaltwerk ausgebaut 10 Minuten, 10 €; neues Schaltwerk eingebaut 10 Minuten, 10 €.

  4. Braucht die Reparatur Teile, gibt Reparatur durchführen eine "Materialbestellung" an Materialbeschaffung. Materialbeschaffung bestellt beim Großhändler (ADR-006).

  5. Nach Abschluss schickt Reparatur durchführen "Info über Updates" an das EMail System. Die Kund:in erhält eine E-Mail (ADR-007). SMS ist vorgesehen, nicht gebaut.

  6. Reparatur durchführen meldet den "Preis" an Bezahlung und die "Rechnungselemente" an das Rechnungswesen (Board Seite 9).

  7. Kund:in holt das Fahrrad ab und bezahlt. Im Laden kassiert die Shop-Mitarbeiter:in; Bezahlung tauscht den Zahlungsstatus mit der Kasse über REST aus. Online klickt die Kund:in den Bezahlen-Button, wird zum Online Payment Service umgeleitet und kommt zurück; Bezahlung fragt den Buchungsstatus per REST ab (ADR-004).

  8. Shop-Mitarbeiter:in schließt die Abholung ab (Story "Repariertes Fahrrad abholen").

Besonderheiten

Reparatur durchführen ist die Drehscheibe. Alle Pfeile nach außen außer Kasse und Payment Service gehen von ihm aus. Die gelbe Notiz "ggf. finanziellen Aspekt separieren?" (Kapitel 5) zielt auf die Schritte 6 und 7.

Note
 Offen: Ob "Preis" und "Rechnungselemente" bei Abschluss, bei Abholung oder je Position fließen, ist nicht entschieden. Fest steht seit Folge 112, dass die Rechnungselemente aus Reparatur durchführen kommen, weil nur dieses Modul weiß, was repariert wurde; Bezahlung meldet nur "250 Euro bezahlt" (60:13 bis 61:36). Ob Bezahlung dem Rechnungswesen zusätzlich "Rechnung ist bezahlt" meldet, hat Eberhard offen gelassen: "Weiß ich nicht, könnte auch im Hintergrund laufen" (63:16, ADR-012). Ob die Materialbestellung vor oder während der Reparatur ausgelöst wird, zeigt das Board nicht. Welche Quelle gilt, wenn Kasse und Payment Service verschiedene Zahlungsstatus liefern (R-011), ist offen.

Fehlerszenario: Webshop nicht erreichbar

Der Webshop trägt Login und Nutzerdaten (ADR-001). Fällt er aus, scheitern Login und Adressabfrage. Das ist Risiko R-002 aus ADR-001 und trifft das Qualitätsziel Verfügbarkeit für Kund:innen: 99,9 % zwischen 7 und 24 Uhr (ADR-008).

06 fehler webshop
Was Board und ADRs hergeben

  • Die Umleitung von /reparatur liegt vor dem Webshop (ADR-002, R-005). Antwortet der Webshop nicht, erreicht die Kund:in auch das Reparatur-System nicht, es sei denn, ein Reverse Proxy vor dem Webshop leitet weiter.

  • Ohne Webshop gibt es kein JWT-Cookie und keine Adressabfrage. Das Reparatur-System kann die Kund:in nicht identifizieren (ADR-001).

  • Die Werkstatt im Laden ist nicht betroffen, sofern Mechaniker:innen sich nicht über den Webshop anmelden.

  • Das Board (Seite 6) setzt für den Wiederanlauf des Web-Systems keine Zeit, nur für das System im Shop (30 Minuten; die Karte "5 Minuten" ist im Video nicht belegt, Kapitel 10).

Note
 Offen: Verhalten nicht entschieden. Weder Board noch ADRs sagen, ob das Reparatur-System eine Fehlermeldung zeigt, den Aufruf wiederholt (Retry) oder ein bereits ausgestelltes JWT weiter akzeptiert. Ob Mechaniker:innen einen Login über den Webshop brauchen, ist nicht entschieden.

Fehlerszenario: Kasse aus der Cloud nicht erreichbar

Die Kasse steht im Laden. Läuft das Reparatur-System in der Cloud, muss Bezahlung die Kasse über das Netz des Ladens erreichen. Das Board fragt auf Seite 10 und 11: "Kann man aus der Cloud in die Kasse kommunizieren?". Das ist Risiko R-010 aus ADR-004. Folge 113 behandelt die Frage (24:38 bis 27:23), entscheidet sie nicht und stuft sie hoch ein: "ich habe potenziell etwas, was mir meinen Ansatz kaputt machen kann" (26:14), "das kann mir im Extremfall die Lösungsstrategie zerstören" (26:57).

06 fehler kasse
Was Board und ADRs hergeben

  • Das Qualitätsszenario "Das System im Shop fällt aus. Spätestens nach 2 Minuten kann man den Preis einer erfolgten Reparatur wieder ermitteln" (Board Seite 6) zeigt, dass der Preis auch bei Ausfall verfügbar sein muss. Für die Kasse selbst gibt es kein Szenario.

  • Eberhard nennt die Integration mit lokalen Systemen "vielleicht in der Cloud schwierig" (Folge 111, 59:46, zitiert in ADR-004).

  • Der zweite Bezahlweg über den Online Payment Service bleibt offen, wenn die Kasse nicht antwortet; Online Payment lässt sich "sicher aus der Cloud anschließen" (Folge 113, 24:10).

  • Folge 113 nennt vier Optionen für die Anbindung: direkt REST aus der Cloud, weil "Kassensysteme heutzutage im Prinzip auch PCs" sind (24:38); ein Kassenproxy im Laden, vorgeschlagen von Zuschauer Jan und für Eberhard "eine mögliche Lösung" (29:27); ein Server im Laden; eine Änderung am Kassensystem (27:07). Der Bezahlvorgang, den die Anbindung tragen muss: Mensch wählt die Rechnung, Kasse erhält "20 Euro kassieren", Buchhaltung folgt (25:21 bis 25:43). Die Frage gilt für Monolith und Microservices gleichermaßen (26:34 bis 26:50).

Note
 Offen: Verhalten nicht entschieden. Ob Bezahlung den Aufruf wiederholt, den Betrag zwischenspeichert oder die Shop-Mitarbeiter:in an der Kasse ohne Systemeintrag kassieren lässt, sagt das Board nicht. Cloud ist seit Folge 113 entschieden (ADR-013); die Anbindung der Kasse aus der Cloud will Eberhard recherchieren (27:07), keine der vier Optionen ist gewählt (Kapitel 7, ADR-004).

Fehlerszenario: Netzausfall im Laden

Zuschauer Jan fragt in Folge 113, was passiert, wenn der Router im Laden ausfällt und das System aus Kundensicht nicht erreichbar ist (08:24). Das Reparatur-System in der Cloud läuft weiter; Werkstatt und Kasse erreichen es nicht, bis das Netz im Laden wieder steht. Betroffen sind die Werkstattfunktionen und die Preisermittlung bei Abholung (QS-Z-02, QS-Z-03); Kund:innen im Web merken nichts. Das Szenario kommt ohne Diagramm aus, weil der Ablauf dem Kassen-Szenario gleicht, nur fehlt die Verbindung in beide Richtungen.

Eberhard liest das Szenario nicht als "nicht mein Problem", sondern als Erwartungshaltung des Kunden, die er mit Optionen und Preis zurückspielt (09:55, 12:32). Drei Optionen nennt er (08:24 bis 14:13): das Risiko akzeptieren; einen mobilen LTE/5G-Router mit automatischem Failover als Reserve, "kostet einen Router und Netzwerktricks, nicht wahnsinnig teuer" (12:52 bis 13:02); einen Cache-Server im Laden, der die Preise vorhält, verworfen, weil er Wartung braucht, innerhalb von 30 Minuten vor Ort sein müsste und "deutlich mehr Geld" kostet (13:10 bis 13:21). Erwartete Entscheidung: Risiko akzeptieren, "vielleicht noch einen mobilen Router als Fallback" (13:43; ADR-018). Anders läge der Fall bei der "Maschinensteuerung eines Atomkraftwerks" (13:47).