Kund:innen sollen ihr Fahrrad online zur Reparatur anmelden. Der Fahrradladen betreibt bereits einen Webshop mit eigener User-Datenbank. Braucht das Reparatursystem eine eigene Nutzerverwaltung mit Registrierung und Login, oder übernimmt es Konten und Anmeldung aus dem Webshop?

Der Webshop ist ein bestehendes Fertigprodukt. Wer dort registriert ist, hat schon Name, Adresse und bevorzugte Zahlungsart hinterlegt. Der Webshop stellt nach dem Login ein JWT als Cookie aus und bietet eine REST-Schnittstelle für Nutzerdaten.

Die Qualitätsziele setzen die Rangfolge (41:44, 58:03): Benutzerfreundlichkeit für Kund:innen steht an erster Stelle, dann Änderbarkeit Richtung SaaS, dann Verfügbarkeit. Security und Confidentiality stuft Eberhard bewusst niedrig ein, weil es am Ende um Fahrradreparaturdaten geht. Die Usability-Szenarien verlangen, dass eine Reparatur in zwei Minuten beauftragt ist und eine Registrierung eine Minute dauert.

Betroffene Qualitätsszenarien: QS-U-01, weil die Registrierung im Webshop bleibt und das Szenario im Reparatursystem damit nicht erfüllbar ist; QS-U-02, weil Login und vorbelegte Adresse aus dem Webshop die Beauftragung in zwei Minuten erst möglich machen; QS-Z-04, weil der Web-Login mit dem Webshop ausfällt (R-002); QS-A-01, weil die feste Kopplung an diesen einen Webshop den Umbau zum SaaS verteuert (R-003).

Option A: Eigene Nutzerverwaltung. Das Reparatursystem führt eigene Konten mit Registrierung, Login und Passwortverwaltung. Vorteil: Das System bleibt unabhängig vom Webshop und hat die Hoheit über seine Kundendaten. Nachteil: Bestehende Webshop-Kund:innen müssen sich ein zweites Mal registrieren und ihre Adresse erneut eingeben.

Option B: Nutzerverwaltung und Login über den Webshop. Kund:innen melden sich im Webshop an. Das Reparatursystem liest das JWT-Cookie des Webshops und holt Adresse und Zahlungsart über dessen REST-Schnittstelle. Vorteil: Kein zweites Konto, das Auftragsformular ist vorbelegt. Nachteil: Das Reparatursystem hängt vom Webshop ab, und die Kundendaten liegen in dessen User-Datenbank.

Option B ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

Die ungewichtete Summe endet unentschieden. Den Ausschlag gibt die Rangfolge der Qualitätsziele: Benutzerfreundlichkeit für Kund:innen steht an erster Stelle, Datenhoheit und Security stehen bewusst weiter unten.

Wir führen keine eigene Nutzerverwaltung. Wir übernehmen die Konten des Webshops: Kund:innen loggen sich im Webshop ein, das Reparatursystem liest das JWT-Cookie und fragt Adresse und Zahlungsart über die REST-Schnittstelle des Webshops ab. Die Registrierung bleibt im Webshop.

Das Geschäftsziel entscheidet. Kund:innen sollen online Reparaturen beauftragen, und das gelingt nur, wenn das System benutzerfreundlich ist (41:44). Eberhard formuliert den Wunsch direkt: "es wäre total super, wenn sich dort jemand registriert hat, dass diese Personen gleich Reparatur beauftragen" (15:36). Dafür muss das Reparatursystem "mit dieser Datenbank von dem Webshop interagieren" (15:59) und dort Adresse und Zahlungsart nachfragen (16:11).

Für den Login greift er zum Standard, den der Webshop schon liefert: "ich logge mich ein bei dem Webshop, dann kriege ich einen JWT als Cookie" (28:34). Über dieses Cookie erfährt das Reparatursystem, wer gerade arbeitet, und tauscht darüber die Benutzerinformation aus (28:59). Die Adresse holt es zusätzlich über eine REST-Schnittstelle (29:10).

Die Registrierung im Reparatursystem entfällt damit ganz. Das Usability-Szenario "Registrierung in einer Minute" erklärt Eberhard später für nicht erfüllbar, weil die Registrierung im Webshop liegt (46:00).

Positiv

Negativ

Risiken

Folgeentscheidung

Aus R-004 folgt ADR-002: Reparatursystem als Pfad unter der Webshop-Domain: Das Reparatursystem läuft unter dem Pfad /reparatur der Webshop-Domain, bestimmte URLs werden dorthin umgeleitet.

Das Reparatursystem ist eine eigene Anwendung neben dem Webshop. Kund:innen erreichen es über den Browser. Unter welcher URL läuft es: unter einer eigenen Domain, unter einer Subdomain des Webshops oder als Pfad unter der Domain des Webshops?

ADR-001: Nutzerverwaltung und Login über den Webshop legt fest, dass Kund:innen sich im Webshop anmelden und das Reparatursystem das JWT-Cookie des Webshops liest. Risiko R-004 aus ADR-001: Nutzerverwaltung und Login über den Webshop benennt die Hürde: Der Browser sendet ein Cookie nur an die Domain, für die es gesetzt wurde. Zuschauer Jan bringt den Hinweis im Chat: "bei dem Cookie die Same-Origin-Policy beachten" (31:24).

Der Webshop ist ein Fertigprodukt. Sein Login und seine Cookie-Einstellungen liegen außerhalb unserer Verantwortung. Änderungen daran sind nicht vorgesehen.

Die Qualitätsziele setzen die Rangfolge (41:44, 58:03): Benutzerfreundlichkeit für Kund:innen zuerst, dann Änderbarkeit Richtung SaaS, dann Verfügbarkeit. Security stuft Eberhard bewusst niedrig ein.

Betroffene Qualitätsszenarien: QS-U-02, weil der Login aus dem Webshop nur unter derselben Domain durchläuft und Kund:innen sich sonst ein zweites Mal anmelden müssten; QS-A-01, weil jeder weitere Laden eine eigene Umleitung unter seiner Domain braucht (R-006).

Option A: Eigene Domain mit Token-Weitergabe. Das Reparatursystem läuft unter einer eigenen Domain, etwa fahrrad-reparatur.de. Das JWT-Cookie des Webshops kommt dort nicht an. Der Webshop müsste das Token beim Absprung übergeben, etwa als URL-Parameter oder über einen Redirect-Flow. Vorteil: Das Reparatursystem ist vom Webshop technisch entkoppelt und lässt sich unverändert für andere Läden betreiben. Nachteil: Der Webshop müsste mitspielen, und ein Token in der URL ist angreifbar.

Option B: Subdomain des Webshops. Das Reparatursystem läuft unter reparatur.meintollerfahrradshop.de. Der Browser sendet das Cookie nur mit, wenn der Webshop es mit einem Domain-Attribut für alle Subdomains setzt. Vorteil: Eigene Infrastruktur, sauber getrennt vom Webshop. Nachteil: Die Cookie-Einstellung des Fertigprodukts entscheidet, ob der Login funktioniert. Das Video behandelt diese Option nicht.

Option C: Pfad unter der Webshop-Domain. Bestimmte URLs werden an das Reparatursystem umgeleitet: meintollerfahrradshop.de/reparatur. Der Browser sendet das JWT-Cookie automatisch mit, weil Domain und Origin gleich bleiben. Vorteil: Der Login aus ADR-001: Nutzerverwaltung und Login über den Webshop funktioniert ohne Umbau am Webshop. Nachteil: Ein Reverse Proxy oder eine Umleitung vor dem Webshop muss den Pfad an das Reparatursystem geben.

Option C ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

Option B endet rechnerisch gleichauf mit der Referenz. Den Ausschlag gibt die Randbedingung: Der Webshop ist ein Fertigprodukt, und nur Option C braucht keine Annahme über dessen Cookie-Einstellungen.

Wir betreiben das Reparatursystem unter dem Pfad /reparatur der Webshop-Domain. Bestimmte URLs werden vom Webshop an das Reparatursystem umgeleitet. Alles unter /reparatur liegt in unserer Verantwortung.

Die Entscheidung folgt aus ADR-001: Nutzerverwaltung und Login über den Webshop. Die Integration mit dem Webshop "funktioniert darüber, dass wir bestimmte URLs umleiten an unser Reparatursystem" (29:36). Eberhard zieht die Grenze klar: "innerhalb von meintollerfahrradshop.de gibt es Slash Reparatur und Slash Reparatur ist unsere Verantwortung" (29:42).

Den technischen Grund liefert der Chat. Jan erinnert an die Same-Origin-Policy (31:24). Eberhard greift das auf: "Cookies können nur ausgetauscht werden, wenn sie in derselben Domäne registriert sind" (31:28). Und weiter: "das ist auch einer der Gründe, weswegen wir bestimmte URLs umleiten wollen" (31:43). Unter /reparatur "würden dann eben die Cookies vom meintollerfahrradshop, also genau der mit JWT, übertragen werden" (31:48).

Eine eigene Domain diskutiert Eberhard nicht ausdrücklich. Sie scheidet aus, weil sie den Login aus ADR-001: Nutzerverwaltung und Login über den Webshop bricht oder den Webshop zu Änderungen zwingt. Beides widerspricht der Rangfolge der Qualitätsziele.

Positiv

Negativ

Risiken

Bezug

Diese Entscheidung schließt R-004 aus ADR-001: Nutzerverwaltung und Login über den Webshop. Die Wahl des Betriebsmodells (Cloud oder on-premise) bleibt offen und entscheidet, wo Umleitung und Reparatursystem laufen.

Kund:innen sollen eine Reparatur online beauftragen und bezahlen. Der Fahrradladen betreibt bereits einen Webshop, in dem Kund:innen Produkte kaufen und abholen. Bilden wir die Reparatur als Produkt in diesem Webshop ab und nutzen dessen Warenkorb und Bezahlung, oder bauen wir einen eigenen Bereich neben dem Webshop mit eigenem Bezahlvorgang?

Der Webshop ist ein standardisiertes Fertigprodukt. Sein Ablauf ist Kaufen und Abholen: Kund:innen legen Artikel in den Warenkorb, bezahlen und holen die Ware ab. Eine Reparatur läuft anders. Kund:innen beschreiben ein Problem, geben das Fahrrad ab, die Werkstatt prüft Ersatzteile und Aufwand, und der Preis steht oft erst nach der Reparatur fest. Bezahlt wird meist bei der Abholung im Laden.

Die Anforderungen hat Eberhard mit dem Anforderer besprochen. Die Frage kam im Chat auf, als ein Zuschauer vorschlug, über den Webshop zu bezahlen (17:46).

Die Qualitätsziele setzen die Rangfolge (41:44, 58:03): Benutzerfreundlichkeit für Kund:innen zuerst, dann Änderbarkeit Richtung SaaS, dann Verfügbarkeit. Security stuft Eberhard bewusst niedrig ein.

Betroffene Qualitätsszenarien: QS-U-02, weil der eigene Bereich dem fachlichen Ablauf einer Reparatur folgt und der eigene Bezahlvorgang die Beauftragung in zwei Minuten nicht verlängern darf (R-008).

Option A: Reparatur als Produkt im Webshop. Die Reparatur wird ein Artikel im Webshop. Kund:innen legen sie in den Warenkorb und bezahlen über den Bezahlvorgang des Webshops. Vorteil: Kein eigener Bezahlvorgang, kein eigener Payment Service, Login und Nutzerdaten sind ohnehin da. Nachteil: Der Ablauf einer Reparatur passt nicht in Kaufen und Abholen. Preis, Diagnose und Werkstattstatus müssten in ein Fertigprodukt gepresst werden, das dafür nicht gebaut ist.

Option B: Eigener Bereich neben dem Webshop. Das Reparatursystem bekommt einen eigenen Teil der Website. Dort beauftragen Kund:innen die Reparatur und bezahlen über einen eigenen Bezahlvorgang. Login und Nutzerdaten kommen weiterhin aus dem Webshop (ADR-001: Nutzerverwaltung und Login über den Webshop). Vorteil: Der Ablauf folgt dem fachlichen Prozess der Reparatur. Nachteil: Das Reparatursystem braucht einen eigenen Payment Service und eine eigene Integration in die User-Datenbank des Webshops.

Option B ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

Die Referenz liegt vorn. Option A spart Aufwand, aber sie verliert bei den beiden Kriterien, die das oberste Qualitätsziel tragen.

Wir bilden die Reparatur nicht als Produkt im Webshop ab. Wir bauen einen eigenen Bereich der Website neben dem Webshop. Dort beauftragen Kund:innen die Reparatur, und dort gibt es einen eigenen Bezahlvorgang. Konten und Login übernehmen wir weiterhin aus dem Webshop.

Der Webshop ist "ein standardisierter Webshop, in dem im Wesentlichen jeder Sachen kaufen kann und anschließend abholen kann" (17:59). Er ist "ein Fertigprodukt" (18:04). Die Diskussion mit dem Anforderer "hatte ergeben, dass wir jetzt nicht eine Reparatur zu einem Produkt im Webshop haben wollen" (18:09). Eberhards Grund ist die fachliche Passung: "weil das ja irgendwie auch unnatürlich ist, also das ist etwas anderes, über das wir reden" (18:19).

Daraus folgt die Form der Lösung: "ich habe einen eigenen Teil der Webseite, neben dem Webshop, in dem ich sagen kann, ich möchte dieses Fahrrad reparieren" (18:40). Und: "da soll es dann einen eigenen Bezahlvorgang geben" (18:45). Die Abgrenzung formuliert er ausdrücklich: "wir werden nicht in den Webshop uns integrieren in dem Sinne, dass wir ein Produkt haben" (18:50).

Die Entscheidung zieht zwei weitere nach sich. Ein eigener Bezahlvorgang braucht einen Payment Service (ADR-004: Bezahlung über externen Payment Service und Kasse im Laden). Ein eigener Bereich braucht die Integration in die User-Datenbank des Webshops, damit Kund:innen kein zweites Konto anlegen (ADR-001: Nutzerverwaltung und Login über den Webshop).

Positiv

Negativ

Risiken

Bezug

Diese Entscheidung ist der Grund für ADR-001: Nutzerverwaltung und Login über den Webshop (Login aus dem Webshop) und ADR-004: Bezahlung über externen Payment Service und Kasse im Laden (Payment Service und Kasse). Die URL des eigenen Bereichs legt ADR-002: Reparatursystem als Pfad unter der Webshop-Domain fest.

Das Reparatursystem hat einen eigenen Bezahlvorgang (ADR-003: Reparatur als eigener Bereich statt als Webshop-Produkt). Wie wickeln wir die Bezahlung ab? Bauen wir eine eigene Zahlungsabwicklung oder binden wir einen externen Payment Service an? Und reicht Online-Bezahlung, oder muss das System auch die Kasse im Laden einbinden?

Der Fahrradladen ist ein lokaler Shop in Kaiserslautern mit drei bis vier Mitarbeiter:innen und ohne IT-Expert:innen (16:51). Eine eigene Zahlungsabwicklung mit Kreditkarten und Konten würde ein Team für Betrieb und Compliance verlangen, das es nicht gibt.

Kund:innen bezahlen eine Reparatur typischerweise bei der Abholung im Laden. Mitarbeiter:innen oder Mechaniker:innen kassieren dort an einem Kassensystem, "letztendlich so eine Art PC" (21:09). Online-Bezahlung ist der zweite Weg, etwa für Anzahlung oder Vorkasse.

Das Betriebsmodell des Reparatursystems ist offen: Cloud oder on-premise ist "eine Architekturentscheidung, die müssen wir treffen", aber "nicht die erste" (09:49).

Die Qualitätsziele setzen die Rangfolge (41:44, 58:03): Benutzerfreundlichkeit für Kund:innen zuerst, dann Änderbarkeit Richtung SaaS, dann Verfügbarkeit. Security stuft Eberhard bewusst niedrig ein.

Betroffene Qualitätsszenarien: QS-Z-03, weil die Kund:in an der Kasse wartet und der Preis der erfolgten Reparatur dort in zwei Minuten vorliegen muss; QS-U-07, weil ein Laden ohne IT-Experten keine eigene Zahlungsabwicklung betreiben kann; QS-A-01, weil jeder Laden eine andere Kasse hat und die Integration je Laden neu entsteht (R-013).

Option A: Eigene Zahlungsabwicklung, nur online. Das Reparatursystem nimmt Kreditkarten oder Lastschrift selbst entgegen und verbucht sie. Bezahlt wird ausschließlich online. Vorteil: Keine Abhängigkeit von einem Anbieter, keine Gebühren je Transaktion. Nachteil: Zahlungsdaten im eigenen System, hohe Anforderungen an Security und Compliance, Kund:innen können im Laden nicht über das System bezahlen.

Option B: Externer Payment Service, nur online. Ein Anbieter wie PayPal wickelt die Bezahlung ab. Kund:innen zahlen mit PayPal-Konto oder Kreditkarte. Vorteil: Fertige Integration, keine Zahlungsdaten im eigenen System. Nachteil: Wer im Laden bezahlt, läuft am System vorbei; die Bezahlung ist im Reparatursystem nicht sichtbar.

Option C: Externer Payment Service plus Kasse im Laden. Online zahlen Kund:innen über PayPal. Im Laden kassieren Mitarbeiter:innen an der Kasse, und das Reparatursystem tauscht den Zahlungsstatus mit der Kasse über REST aus. Vorteil: Beide Wege der Bezahlung sind im System sichtbar; der Ablauf passt zum Laden. Nachteil: Zwei Integrationen statt einer; die Kasse steht im Laden und ist ein lokales System.

Option C ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

Option B endet rechnerisch gleichauf mit der Referenz. Den Ausschlag gibt die fachliche Randbedingung: Bezahlt wird im Laden, und ein System, das diesen Weg nicht kennt, verfehlt das oberste Qualitätsziel.

Wir bauen keine eigene Zahlungsabwicklung. Online zahlen Kund:innen über einen externen Payment Service, in erster Linie PayPal, mit PayPal-Konto oder Kreditkarte. Die Integration hat zwei Seiten: im Frontend ein Button, der zu PayPal umleitet und zurückführt; im Backend eine REST-Schnittstelle, über die das Reparatursystem den Buchungsstatus abfragt. Zusätzlich integrieren wir die Kasse im Laden über REST, damit Bezahlungen bei der Abholung im System ankommen.

Der eigene Bezahlvorgang aus ADR-003: Reparatur als eigener Bereich statt als Webshop-Produkt "bedeutet, dass wir tatsächlich irgendwie so einen Payment Service brauchen" (19:01). Eberhard denkt "ehrlich gesagt in erster Linie an so ein PayPal" (19:12): "wir werden so einen Button haben, wo wir sagen, bezahlen mit PayPal" (19:22), mit PayPal-Konto oder Kreditkarte (19:26). Eine eigene Abwicklung erwägt er nicht; sie widerspricht der Randbedingung "keine IT-Expert:innen".

Die technische Form beschreibt er im technischen Kontext (30:16): "auf der einen Seite eine Integration hinten über REST, worüber ich abfragen kann, ob das wirklich funktioniert hat" (30:22), und "die UI-Integration, sprich ich habe so einen Button, bezahle per PayPal, der leitet um zu PayPal" (30:32). Sein Urteil: "solche Sachen sind häufig einfach zu integrieren" (30:47).

Die Kasse kommt als zweiter Weg dazu: "es gibt ein Kassensystem, letztendlich so eine Art PC, ein weiteres System, mit dem wir uns integrieren müssen" (21:09). Ausdrücklich: "wir werden nicht nur Online-Payments machen, sondern uns auch mit der Kasse integrieren müssen" (21:23). Als Protokoll trägt er "ein REST-Protokoll Richtung Kasse" ein (30:52).

Positiv

Negativ

Risiken

Bezug

Die Bezahlung ist die Folge von ADR-003: Reparatur als eigener Bereich statt als Webshop-Produkt. Die Bezahlart der Kund:innen kommt aus dem Webshop (ADR-001: Nutzerverwaltung und Login über den Webshop). R-010 verbindet diese Entscheidung mit dem noch offenen Betriebsmodell.

Kund:innen wollen wissen, ob ihr Fahrrad fertig ist. Der Webshop kennt die Kund:innen (ADR-001: Nutzerverwaltung und Login über den Webshop), das Reparatursystem kennt den Reparaturstatus. Muss das Reparatursystem seine Daten in den Webshop spielen, damit Kund:innen den Status dort sehen, oder zeigt es den Status auf einer eigenen Seite?

Der Webshop ist ein Standard-Fertigprodukt für Kaufen und Abholen (17:59). Eine Reparatur ist dort kein Produkt; das Reparatursystem bekommt einen eigenen Bereich neben dem Webshop mit eigenem Bezahlvorgang (18:40). Die Integration mit dem Webshop beschränkt sich auf User-Datenbank und Login.

Aus dem Chat kommt die Frage, ob der Webshop Daten aus dem Reparatursystem braucht oder ob ein regelmäßiger Datenabgleich reicht (19:35). Eberhard ordnet die Frage unterhalb der aktuellen Flughöhe ein: Auf der Ebene des Systemkontexts geht es zunächst darum, welche Systeme überhaupt zu integrieren sind (19:49). Trotzdem ergibt sich die Antwort schon aus den bisherigen Ideen (20:02).

Die Qualitätsziele setzen die Rangfolge (41:44, 58:03): Benutzerfreundlichkeit für Kund:innen zuerst, dann Änderbarkeit Richtung SaaS, dann Verfügbarkeit. Security steht bewusst weiter unten.

Betroffene Qualitätsszenarien: QS-U-03, weil die Statusseite das ist, was Kund:innen nach der Reparatur vom System sehen und bewerten (R-014, R-015); QS-A-01, weil Reparaturdaten genau einen Ort haben und andere Läden mit anderen Webshops keinen Abgleich brauchen.

Option A: Datenabgleich mit dem Webshop. Das Reparatursystem überträgt Reparaturaufträge und Status regelmäßig in den Webshop. Kund:innen sehen den Status in ihrem gewohnten Kundenkonto. Vorteil: Ein Ort für alles, was die Kund:innen mit dem Laden zu tun haben. Nachteil: Das Fertigprodukt Webshop muss Reparaturdaten aufnehmen und anzeigen, und der Abgleich läuft mit Verzögerung.

Option B: Eigene, vom Reparatursystem gerenderte Statusseite. Der Webshop hält keine Reparaturdaten. Kund:innen rufen unter dem Reparaturbereich eine Seite auf, die das Reparatursystem selbst rendert und die den aktuellen Status zeigt. Vorteil: Kein Datenaustausch in Richtung Webshop, der Status ist immer aktuell. Nachteil: Der Reparaturstatus steht nicht im Kundenkonto des Webshops.

Option B ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

Die Summe spricht für Option B. Den Ausschlag gibt die Trennung der Verantwortung: Der Webshop bleibt, was er ist, und das Reparatursystem hält seine Daten selbst.

Wir tauschen keine Reparaturdaten mit dem Webshop aus. Der Webshop hält keine Daten aus dem Reparatursystem. Das Reparatursystem rendert eine eigene Statusseite, auf der Kund:innen nach dem Login sehen, ob ihr Fahrrad fertig ist.

Eberhard beantwortet die Chat-Frage direkt: "der Webshop hat keine Daten aus dem Reparatursystem" (20:06). Stattdessen gibt es eine Seite, "die wir selber rendern, deswegen müssen wir die Daten nicht austauschen" (20:22). Er beschreibt den Ablauf aus Kundensicht: Ich gehe auf die Webseite, sage, wer ich bin, und das System antwortet, ob das abgelieferte Fahrrad fertig ist (20:13).

Die Entscheidung folgt aus ADR-003: Reparatur als eigener Bereich statt als Webshop-Produkt: Der Reparaturbereich liegt neben dem Webshop, nicht in ihm (18:45). Wer dort beauftragt, schaut auch dort nach. Ein Abgleich würde das Fertigprodukt um eine Funktion erweitern, die es nicht hat.

Eberhard merkt an, dass die Frage eigentlich unter der aktuellen Granularität liegt (19:49). Sie lässt sich trotzdem schon beantworten, und die Antwort passt zu dem Bild, das der Systemkontext gerade zeichnet: wenige, klar geschnittene Schnittstellen.

Positiv

Negativ

Risiken

Verwandte Entscheidungen

Die Statusseite liegt unter dem Pfad /reparatur der Webshop-Domain (ADR-002: Reparatursystem als Pfad unter der Webshop-Domain), damit das JWT-Cookie des Webshops den Login trägt (ADR-001: Nutzerverwaltung und Login über den Webshop).

Eine Reparatur braucht Ersatzteile. Die Werkstatt muss wissen, ob ein Teil da ist, was es kostet und wann es nachbestellt werden muss. Führt das Reparatursystem diese Bestände selbst, oder bindet es ein Inventar- oder Warenwirtschaftssystem an?

Der Fahrradladen ist klein: drei bis vier Leute, kein IT-Betrieb (16:22). Das Backlog nennt, dass Ersatzteile bestellt werden können und dass Reparaturen protokolliert werden (25:04). Beides deutet darauf hin, dass das System Teile zumindest zum Teil verfolgt (25:09).

Aus dem Chat kommt der Hinweis, ein Inventarsystem für Teile des Rades in den Systemkontext aufzunehmen (22:13). Eberhard nennt das "eine spannende Frage" (22:25). Der Systemkontext hat zu diesem Zeitpunkt schon viele Schnittstellen: Webshop, User-Datenbank, Payment Service, Kasse, Rechnungswesen, E-Mail-Dienst.

Die Qualitätsziele setzen die Rangfolge (41:44, 58:03): Benutzerfreundlichkeit zuerst, dann Änderbarkeit Richtung SaaS, dann Verfügbarkeit. Security steht bewusst weiter unten.

Betroffene Qualitätsszenarien: QS-U-07, weil ein Inventarsystem weniger ein System weniger ist, das der Laden ohne IT-Experten betreiben müsste; QS-A-01, weil Läden mit eigenem Inventarsystem als SaaS-Kunden auf die Eigenlösung treffen (R-018).

Option A: Inventar- oder Warenwirtschaftssystem anbinden. Ein externes System führt Bestände, Preise und Bestellungen. Das Reparatursystem fragt dort nach und bucht Verbrauch zurück. Vorteil: Lagerverwaltung ist ein gelöstes Problem, ein Fertigprodukt kann mehr als eine Eigenlösung. Nachteil: Eine weitere Schnittstelle, ein weiteres System, das jemand betreiben muss, und der Laden hat heute keines.

Option B: Ersatzteile im Reparatursystem selbst führen. Das Reparatursystem hält selbst fest, welche Teile vorrätig sind und was sie kosten, und löst Bestellungen aus. Vorteil: Keine Schnittstelle, eine klare Verantwortung. Nachteil: Das Reparatursystem baut eine kleine Lagerverwaltung nach.

Option B ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

Die Summe spricht für Option B. Den Ausschlag gibt die Verantwortung: Das Reparatursystem soll die Teile prüfen, also führt es sie auch.

Wir führen Ersatzteile und Werkzeuge im Reparatursystem selbst. Das System weiß, welche Teile vorrätig sind und was sie kosten, und es löst Bestellungen aus. Wir binden kein Inventar- oder Warenwirtschaftssystem an.

Eberhard legt die Annahme offen: Das System, das die Reparatur macht, soll "selber Buch führen über Ersatzteile" (22:30). Sein Beispiel ist ein Schaltwerk, das noch da ist und so viel Euro kostet: "das wollen wir halt im Reparatursystem selber drin haben" (22:49).

Der Systemkontext liefert ihm das Argument. Er hat gerade definiert, welche Verantwortung das System hat: "wir müssen eben die Ersatzteile checken" (23:04). Daraus folgt: "wir müssen uns eben nicht integrieren mit irgendeinem anderen System" (23:12). Er nennt das ausdrücklich "eine Entscheidung, die wir jetzt getroffen haben" (23:15). Genau für solche Entscheidungen hält er das Kontextdiagramm für wertvoll (22:59).

Die fachliche Verantwortung selbst gehört nicht ins Kontextdiagramm, sondern in die Anforderungen (24:38). Das Diagramm sagt nur, mit welchen Systemen wir Schnittstellen haben, und das Inventarsystem ist keines davon.

Positiv

Negativ

Risiken

Verwandte Entscheidungen

Die fachliche Verantwortung "Ersatzteile prüfen" steht in den Anforderungen, nicht im Kontextdiagramm (24:38).

Ist die Reparatur fertig, sollen Kund:innen das erfahren, ohne im Laden anzurufen. Über welchen Kanal benachrichtigt das Reparatursystem: E-Mail, SMS, beides oder Push über eine App?

Kund:innen beauftragen die Reparatur online und holen das Fahrrad im Laden ab (18:04). Zwischen Abgabe und Abholung liegt die Werkstattzeit; eine Benachrichtigung schließt diese Lücke. Der Laden hat keine IT-Experten (53:59); jeder Dienst, den das System braucht, wird eher gekauft als betrieben (54:18).

Der Kanal ist eine Frage der Erreichbarkeit. Eberhard hält sich selbst für "eher oldschool" (23:58) und weiß, dass andere Kund:innen anders erreichbar sind. Das Betriebsmodell des Systems ist noch offen (59:33); ein Cloud-Dienst für E-Mail passt zu beiden Richtungen.

Die Qualitätsziele setzen die Rangfolge (41:44, 58:03): Benutzerfreundlichkeit für Kund:innen zuerst, dann Änderbarkeit Richtung SaaS, dann Verfügbarkeit. Security steht bewusst weiter unten.

Betroffene Qualitätsszenarien: keines. Die Entscheidung folgt aus einer Randbedingung, nicht aus einem Szenario. QS-U-03 nennt die Benachrichtigung als Antwort der Architektur, treibt aber nicht die Wahl des Kanals.

Option A: E-Mail. Das Reparatursystem schickt eine E-Mail über einen gekauften Dienst wie AWS Simple Email Service. Vorteil: Jede:r Webshop-Kund:in hat eine E-Mail-Adresse, der Dienst ist fertig und billig. Nachteil: E-Mails werden spät gelesen oder landen im Spam.

Option B: SMS. Das Reparatursystem schickt eine SMS über einen SMS-Gateway. Vorteil: Erreicht Kund:innen sofort auf dem Telefon. Nachteil: Braucht eine Mobilnummer, die der Webshop nicht unbedingt kennt, und kostet je Nachricht.

Option C: E-Mail und SMS. Beide Kanäle, Kund:innen wählen. Vorteil: Beste Erreichbarkeit. Nachteil: Zwei Integrationen, zwei Dienste, eine Kanalwahl in der Oberfläche.

Option D: Push über eine App. Vorteil: Direkter Kanal. Nachteil: Eine eigene App für einen lokalen Fahrradladen, den Kund:innen wenige Male im Jahr brauchen.

Option A ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

Die Summe trennt die Optionen kaum. Den Ausschlag gibt die Einfachheit: E-Mail ist mit einer gekauften Schnittstelle erledigt und braucht keine Daten, die der Webshop nicht hat.

Wir benachrichtigen Kund:innen per E-Mail über einen gekauften Dienst wie AWS Simple Email Service, angebunden über eine Schnittstelle des Anbieters. Wir sehen einen SMS-Kanal vor, ohne ihn jetzt zu bauen: Die Benachrichtigung ist im System so gekapselt, dass ein zweiter Kanal später hinzukommt, ohne die Reparaturlogik zu ändern. Push über eine App bauen wir nicht.

Eberhard setzt E-Mail als Erstes: "wir wollen noch den Kunden darüber informieren, dass die Reparatur fertig ist, und dazu schicken wir eine E-Mail" (23:30). Beim Nachdenken kommt der Zweifel: SMS könnte passender sein, E-Mail "vielleicht nicht so super smart" (23:52). Er begründet seine Wahl mit sich selbst, "mich erreicht man tatsächlich über E-Mail" (23:58), und hält die Tür offen: "vielleicht sollten wir da auch noch eine SMS-Integration vorsehen" (24:04).

Technisch ist E-Mail ein Kaufteil. Beim technischen Kontext nennt er den Simple Email Service von AWS als Beispiel für Dinge, "die man halt bei AWS kaufen kann" (31:02), aufrufbar "über eine Schnittstelle, meinetwegen auch eine REST-Schnittstelle" (31:11). Da das System den E-Mail-Dienst nicht selbst baut, ist das Protokoll für ihn "nicht so super spannend" (31:19).

Die SMS bleibt unentschieden. Eberhard sagt "vorsehen", nicht "bauen". Wir lesen das als Auftrag, den Kanal austauschbar zu halten, und als Frage an den Fachexperten, wie die Kund:innen des Ladens erreichbar sein wollen.

Positiv

Negativ

Risiken

Offene Frage

Ob und wann SMS kommt, entscheidet der Fachexperte anhand der Erreichbarkeit der Kund:innen. Diese Entscheidung ist nicht getroffen.

Das Reparatursystem hat zwei Nutzergruppen: die Werkstatt im Laden und die Kund:innen im Web. Gilt für das ganze System ein Verfügbarkeitsziel, oder bekommen Werkstatt und Web verschiedene Ziele, abhängig von der Tageszeit? Die Antwort ist eine Qualitätsanforderung, aber sie erzwingt Architekturmaßnahmen: Betriebsmodell, Provider-SLAs, Wiederanlauf und Datensicherung.

Der Laden öffnet um 9 Uhr und schließt um 18 Uhr (56:21). Der Laden hat keine IT-Experten, das System soll dennoch betrieben werden können (53:59). Das Betriebsmodell ist offen: Cloud, on-premise oder Fremdbetrieb (59:33). Eberhard hält fest, dass genau diese Constraints das Betriebsmodell beeinflussen (60:13).

Die Qualitätsziele setzen die Rangfolge (41:44, 58:03): Benutzerfreundlichkeit für Kund:innen zuerst, dann Änderbarkeit Richtung SaaS, dann Verfügbarkeit. Die Verfügbarkeitsanforderungen nennt Eberhard "eher entspannt" (59:18). Security steht bewusst weiter unten.

Betroffene Qualitätsszenarien: QS-Z-01 und QS-Z-02, weil sie das Werkstatt-Ziel mit 99 % zu Ladenzeiten und 30 Minuten Wiederanlauf tragen; QS-Z-04, QS-Z-05 und QS-Z-06, weil sie das Web-Ziel mit 99,9 % tagsüber, 99 % nachts und schnellerem Wiederanlauf tragen; QS-Z-03, weil der Preis an der Kasse schon nach zwei Minuten wieder vorliegen muss und dieses Ziel zum Werkstatt-Ziel passen muss; QS-Z-07, weil der Datenverlust von höchstens fünf Minuten die Persistenz bindet (R-024); QS-U-07, weil 99,9 % ohne IT-Experten nur mit Fremdbetrieb oder Provider-SLA erreichbar sind.

Option A: Ein hohes Ziel für alles. 99,9 % rund um die Uhr für Werkstatt und Web. Vorteil: Ein Ziel, eine Architektur, keine Unterscheidung. Nachteil: Die Werkstatt bezahlt eine Verfügbarkeit, die sie nicht braucht; nachts läuft das System für niemanden.

Option B: Ein niedriges Ziel für alles. 99 % zu Ladenzeiten für Werkstatt und Web. Vorteil: Billig und einfach zu erfüllen, auch on-premise. Nachteil: Im Web kostet jede Ausfallminute Umsatz, und Kund:innen beauftragen abends.

Option C: Differenziert. Werkstatt: 99 % zwischen 9 und 18 Uhr, Wiederanlauf spätestens nach 30 Minuten. Web: 99,9 % zwischen 7 und 24 Uhr, nachts 99 % mit schnellerem Wiederanlauf. Daten, die fünf Minuten vor einem Ausfall erfasst wurden, überleben ihn. Vorteil: Jede Nutzergruppe bekommt, was sie braucht. Nachteil: Zwei Ziele bedeuten zwei Betriebsprofile in einem System.

Option C ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

Die ungewichtete Summe spricht für Option B. Den Ausschlag gibt das Geschäft: Kund:innen sollen online beauftragen, und jede Ausfallminute im Web ist Umsatzausfall (56:52). Option B verfehlt das Ziel, für das das System gebaut wird.

Wir differenzieren die Verfügbarkeitsziele nach Nutzergruppe und Tageszeit:

Diese Ziele gehen als Qualitätsszenarien in Kapitel 10 und als Constraints in die Entscheidung über das Betriebsmodell.

Eberhard schreibt die Szenarien als Stimulus und Response auf. Für die Werkstatt: "Ein Mitarbeiter im Shop will das System zwischen 9 und 18 Uhr benutzen und es steht zu 99 Prozent zur Verfügung" (55:07), nach einem Ausfall "spätestens nach 30 Minuten wieder" (55:21). Für das Web: "Das Websystem soll zu 99,9 Prozent zur Verfügung stehen" (55:42), zwischen 7 und 24 Uhr (56:02). Nachts "haben wir nicht so viele Kunden", weniger ist akzeptabel, "aber das System soll schneller wieder anlaufen" (56:07).

Die Differenz begründet der Auftraggeber. Fällt das System um 18 Uhr für eine Minute aus, "ist es egal" (56:32). Dreißig Minuten sind akzeptabel, "weil man kann sich 30 Minuten lang mit Zettel und Bleistift über Wasser halten" (56:39). Im Internet ist das anders: "Jede Minute, die wir nicht haben, führt zu einem Umsatzausfall. Also müssen wir da besser sein" (56:52).

Den Datenverlust begrenzt er getrennt: Was fünf Minuten vor dem Ausfall erfasst wurde, soll ihn "praktisch sicher" überstehen, "damit nicht plötzlich ein Reparaturauftrag weg ist" (57:12). Ein verlorener Auftrag "fährt einfach unschön" (57:22).

Positiv

Negativ

Risiken

Verwandte Entscheidungen

Die Verfügbarkeitsziele und die Randbedingung "keine IT-Experten" fließen in die Entscheidung über das Betriebsmodell (A1, vertagt). Der Wiederanlauf in 30 Minuten und der Datenverlust von 5 Minuten setzen die Response Measures der Kapitel-10-Szenarien.

Das Reparatursystem soll die Stories aus Folge 111 umsetzen: Fahrrad zur Reparatur anmelden, Termin berechnen, Defekt aufnehmen, Protokoll führen, Kosten berechnen, bezahlen, Ersatzteile und Werkzeuge bestellen. Nach welchem Kriterium teilen wir das System auf oberster Ebene in Module, und wie viele Module ergeben sich daraus?

Eberhard strukturiert das System live am Board entlang der Stories. Er wählt bewusst einen leichtgewichtigen Weg statt Event Storming oder Domain Storytelling, weil er "konzeptionell da durchführen" will (21:33). Die Stories liegen räumlich sortiert: oben die Kundenperspektive, unten die Sicht der Mechaniker:in (24:33). Die Rangfolge der Qualitätsziele aus Folge 111 gilt weiter: Benutzerfreundlichkeit, dann Änderbarkeit Richtung SaaS, dann Verfügbarkeit.

Der Schnitt entsteht induktiv beim Gruppieren. Nacheinander entstehen Terminplanung (24:51), Reparatur durchführen (30:14), Bezahlung (45:16) und Materialbeschaffung (47:23). Das Kriterium bleibt jedes Mal dasselbe: Ein Modul bekommt ein eigenes Domänenmodell mit eigenen Daten, die als Beispiel neben die Box geschrieben werden.

Betroffene Qualitätsszenarien: Keines direkt. Eberhard begründet den Schnitt mit den fachlichen Anforderungen, nicht mit einem Qualitätsszenario (22:41). QS-A-01 ist mittelbar betroffen, weil ein Schnitt nach Fachlichkeit die Stelle eingrenzt, an der ein weiterer Laden eigene Regeln mitbringt; das Video stellt diesen Zusammenhang aber nicht her. Die Einarbeitungsszenarien QS-U-05 und QS-U-06 nennt Eberhard in diesem Zusammenhang nicht.

Option A: Technische Schichten. Das System teilt sich auf oberster Ebene in UI, Logik und Persistenzschicht. Vorteil: Ein vertrautes Muster, jede Schicht hat eine klare technische Aufgabe. Nachteil: Jede Story zieht sich durch alle drei Schichten; die Fachlichkeit findet auf oberster Ebene keinen Ort.

Option B: Fachliche Module. Das System besteht aus vier Modulen, jedes trägt eine Fachlichkeit mit eigenem Domänenmodell: Terminplanung, Reparatur durchführen, Bezahlung, Materialbeschaffung. Vorteil: Jede Story landet in genau einem Modul, die Daten liegen dort, wo sie gebraucht werden. Nachteil: Die Statusseite für Kund:innen braucht Termin und Protokoll aus zwei Modulen.

Option C: Mehr Module. Wie B, zusätzlich ein fünftes Modul Reparaturstatus, das die Kundensicht hält und Datum sowie Protokollstand von den beiden anderen Modulen bezieht. Vorteil: Eine Statusseite aus einer Hand. Nachteil: Das Modul hält dieselben Informationen wie Terminplanung und Reparatur durchführen, nur weniger davon.

Option B ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

Option A scheitert am Zweck der Aufteilung: Sie gibt keine Antwort auf die fachlichen Anforderungen. Option C gewinnt nur bei der Statusseite und zahlt dafür mit einem Modul, das nichts Eigenes weiß.

Wir schneiden das System auf oberster Ebene fachlich in vier Module: Terminplanung, Reparatur durchführen, Bezahlung und Materialbeschaffung. Ein Modul rechtfertigt sich durch ein eigenes Domänenmodell mit eigenen Daten. Es gibt kein Modul Reparaturstatus; den Status ermitteln Terminplanung und Reparatur durchführen gemeinsam, jedes Modul liefert seinen Teil der Statusseite.

Die Schichten fallen zuerst. Eberhard sagt: "ich mache bewusst keine technische Aufteilung" (22:11). UI, Logik und Persistenz findet er "auf dieser grob-granularen Ebene nicht hilfreich" (22:33). Das System soll fachliche Anforderungen erfüllen, und "darauf können wir nur eine Antwort geben, wenn wir das Zeug fachlich strukturieren" (22:54).

Das Kriterium für einen Schnitt nennt er bei Terminplanung und Reparatur durchführen: "zwei unterschiedliche Informationsdichten" (33:21). Das gehe "in diese Richtung von Bounded Contexts" (33:34): gleiche Namen wie "die Reparatur", aber "unterschiedliche Informationen, die damit einhergehen" (33:48). Bezahlung folgt demselben Muster: "da geht es halt tatsächlich nur darum, einen Betrag zu bezahlen" (45:23). Die Preise lägen zwar bei Reparatur durchführen, "aber ich würde es halt, glaube ich, tendenziell trennen" (45:45), denn das Modul hat "keine Informationen mehr über die Reparatur" (46:10). Materialbeschaffung begründet er nur über ihr eigenes Datum: "das vielleicht auch was Eigenes ist" (47:36), es kennt "eine Bestellung bei einem Großhändler" (47:40).

Das fünfte Modul Reparaturstatus prüft er und verwirft es: "Ich finde das in diesem Fall nicht sonderlich sinnvoll" (35:43). Die Kundensicht braucht "exakt diese Informationen, die hier drinstehen" (36:54), "die sind so identisch" (37:08), also "schmeißen wir das mal weg" (37:22). Ein eigenes Modul lohnt sich erst bei "einen sehr begrenzten und auch sehr anderen Blick" (36:07), etwa einer Statistik, die nur zählt, wie viele Schaltungen eingebaut wurden (36:18).

Positiv

Negativ

Risiken

Kund:innen melden ein Fahrrad zur Reparatur an und bekommen einen Termin. Mechaniker:innen nehmen den Defekt auf, bauen Teile ein und führen ein Protokoll. Beides heißt "Reparatur". Gehört alles in ein Modul, oder sind Terminplanung und Reparatur durchführen zwei Module mit eigenem Domänenmodell?

Der fachliche Schnitt aus ADR-009: Fachlicher Modulschnitt statt technischer Schichten verlangt je Modul ein eigenes Domänenmodell mit eigenen Daten. Beim Gruppieren der Stories entsteht links die Terminplanung: "wann ich diese Fahrräder halt eigentlich repariere" (24:51), ein großer Kalender. Rechts entsteht Reparatur durchführen mit Defekt, Protokoll, Ersatzteilen und Kosten. Quer dazu liegt die Story "Status der Reparatur abfragen": Kund:innen wollen auf einer Seite sehen, ob die Reparatur eingeplant ist und was schon getan wurde (31:14).

Aus dem Chat kommt die Frage, ob man die Terminplanung nicht einkaufen könne (37:27). Eberhard entscheidet das nicht, hält es aber offen und ordnet den Fall ein: Eine gekaufte Terminplanung wäre eine Generic Subdomain (41:16).

Betroffene Qualitätsszenarien: Keines direkt. Der Schnitt zielt auf getrennte Domänenmodelle, nicht auf ein Qualitätsszenario. QS-A-01 ist mittelbar berührt, weil eine austauschbare Terminplanung (R-030) den Umbau zum SaaS um ein zu bauendes Modul entlastet; das Video stellt diesen Zusammenhang nicht her.

Option A: Ein Modul Reparatur. Termin, Defekt, Protokoll und Kosten liegen in einem Modul mit einem Domänenmodell. Vorteil: Die Statusseite kommt aus einer Hand, keine Schnittstelle zwischen Termin und Durchführung. Nachteil: Ein Modell muss Kalenderlogik und Werkstattwissen zugleich tragen; die Terminplanung lässt sich nicht getrennt ersetzen.

Option B: Zwei Module. Terminplanung kennt die Reparatur als Termin. Reparatur durchführen kennt sie als Defekt, Ersatzteile, Einbauzeit und Kosten. Beide Module tragen zur Statusseite bei. Vorteil: Zwei schlanke Domänenmodelle, die Terminplanung bleibt generisch. Nachteil: Die Statusseite wird von zwei Modulen gemeinsam hergestellt.

Option B ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

Option A gewinnt bei der Statusseite und der Schnittstelle, verliert aber bei allem, was aus dem getrennten Domänenmodell folgt.

Terminplanung und Reparatur durchführen sind zwei Module. Terminplanung hält den Termin und die Arbeitsplanung, Reparatur durchführen hält Defekt, Protokoll, Ersatzteile und Kosten. Den Status der Reparatur ermitteln beide Module; die Statusseite setzt sich aus beiden Teilen zusammen. Ob die Terminplanung selbst gebaut oder gekauft wird, bleibt offen.

Das tragende Argument ist die Informationsdichte. Eberhard: "diese fachliche Aufteilung ist trotzdem sinnvoll" (33:15), weil "wir hier zwei unterschiedliche Informationsdichten sozusagen haben" (33:21). Links ist die Reparatur "eigentlich als Termin" (33:53), und das "bedeutet Arbeitsplanung" (34:00), die er "auch für mich als Eberhard Wolff, der Berater, nutzen könnte" (34:04). Rechts steckt das Wissen, "dass ich irgendwie Ersatzteile habe, dass ich die einbaue, dass es Zeit kostet" (34:08). Sein Schluss: "Diese beiden Systeme jetzt zusammenzupacken, macht, glaube ich, keinen Sinn" (34:20).

Er ordnet das Muster ein: "ein bisschen geht das in diese Richtung von Bounded Contexts" (33:34). Beide Modelle haben "Dinge, die gleich benannt sind" (33:46), aber "unterschiedliche Informationen, die damit einhergehen" (33:48).

Die Statusseite löst er, ohne den Schnitt aufzugeben: "diese Webseite wird gemeinsam hergestellt von diesen beiden Systemen" (34:27). Terminplanung sagt, wann die Reparatur begonnen wurde, Reparatur durchführen sagt, "wir haben halt übrigens folgende Dinge gemacht" (34:42).

Den Einkauf der Terminplanung schließt er nicht aus: "Das will ich nicht ausschließen" (40:08) und "es steht, glaube ich, außer Frage, dass man eine Terminplanung kaufen kann" (43:58). Beurteilen könne er das aber nicht: "Ich kann das aber nicht ernsthaft bewerten" (40:26), dafür sieht er "andere Personen" (40:27). Bei Standardsoftware nehme man, "was ungefähr passt" (44:18), und "würge das halt irgendwie in den Rest des Systems rein" (44:38).

Positiv

Negativ

Risiken

Folgeentscheidung

Die Richtung der Abhängigkeit zwischen beiden Modulen legt ADR-012: Gerichtete Abhängigkeiten und Zuordnung der externen Systeme fest.

Die Bausteinsicht Level 1 zeigt vier rote Boxen: Terminplanung, Reparatur durchführen, Bezahlung, Materialbeschaffung. Was bedeutet eine Box technisch? Ist eine Komponente ein eigenes Projekt in der Versionskontrolle, oder ein Verzeichnis in einem gemeinsamen Code-Baum?

Eberhard leitet aus dem Kontextdiagramm von Folge 111 die nächste Ebene ab, die arc42-Bausteinsicht Level 1 (48:42). Bevor er die Drittsysteme anschließt, will er die Boxen definieren (54:13). Er hält sich nicht an einen Standard, notiert aber eine eigene Legende: rote Box, Pfeil, grüne Box haben je eine festgelegte Bedeutung (51:16). Die Alternative "Komponente gleich separiertes Verzeichnis im Source Code" schreibt er ausdrücklich mit auf das Board (54:41).

Das Team ist klein. Folge 111 nennt drei bis vier Personen im Shop und keine IT-Expert:innen; das Szenario QS-U-07 verlangt Betrieb ohne IT.

Betroffene Qualitätsszenarien: QS-U-07 mittelbar, weil vier Repositories mit eigener Build-Kette gepflegt werden müssen und der Shop dafür niemanden hat (R-032); das Video stellt diesen Zusammenhang nicht her. QS-A-01 berührt die Entscheidung nicht erkennbar.

Option A: Verzeichnis im gemeinsamen Code. Alle vier Module liegen in einem Repository, jedes in einem eigenen Verzeichnis. Vorteil: Ein Checkout, ein Build, Änderungen über Modulgrenzen in einem Commit. Nachteil: Die Modulgrenze ist eine Konvention; nichts hindert daran, quer durch die Verzeichnisse zu greifen.

Option B: Eigenes Projekt in der Versionskontrolle. Jedes Modul ist ein eigenes Repository mit eigenem Build. Vorteil: Die Grenze ist technisch erzwungen, jedes Modul lässt sich für sich bauen. Nachteil: Vier Repositories, vier Builds, Änderungen über Modulgrenzen brauchen mehrere Commits.

Option B ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

Die ungewichtete Summe endet unentschieden. Den Ausschlag gibt der Zweck des Diagramms: Eberhard will Boxen mit Bedeutung, und er will die Module getrennt bauen können (ADR-012: Gerichtete Abhängigkeiten und Zuordnung der externen Systeme).

Jede der vier Komponenten ist ein eigenes Projekt in der Versionskontrolle: ein Projekt Terminplanung, ein Projekt Reparatur durchführen, ein Projekt Bezahlung, ein Projekt Materialbeschaffung. Die rote Box im Diagramm bedeutet genau das. Die Legende hält die verworfene Alternative fest.

Eberhard definiert die Box, bevor er weiterzeichnet: "Das sind Komponenten und zwar sind das separierte Projekte in der Versionskontrolle" (54:21). Er zählt auf: "ein Projekt Terminplanung, ein Projekt Reparatur durchführen, ein Projekt Bezahlung und ein Projekt Materialbeschaffung" (54:26). Dann sagt er "Das sind drei Git Repositories" (54:36); ein Versprecher, er meint vier, wie er am Ende bestätigt: "es gibt vier Projekte in der Versionskontrolle" (63:39).

Die Begründung ist methodisch, nicht technisch. Er stellt bei Architekturdiagrammen "die relativ unschuldige Frage" (54:55): "Was sind eigentlich diese Boxen?" (54:58). Oft "stellt sich halt heraus, dass diese Boxen in Wirklichkeit keine Semantik haben" (55:00), und das sei "super gefährlich" (55:05): "wenn diese Diagramme keine Semantik haben, dann rede ich halt gerade über nichts" (55:10).

Die technische Folge benennt er kurz darauf: Materialbeschaffung und Bezahlung sollen gebaut werden können, "Reparatur das irgendwie nutzt und Terminplanung das irgendwie nutzt" (57:21), "dass ich also sozusagen eine Build-Reihenfolge habe" (57:27).

Positiv

Negativ

Risiken

Folgeentscheidung

Aus der Build-Reihenfolge folgt ADR-012: Gerichtete Abhängigkeiten und Zuordnung der externen Systeme: Die Abhängigkeiten zwischen den vier Projekten bilden einen gerichteten Graphen.

Vier Projekte (ADR-011: Jede Komponente ist ein eigenes Projekt in der Versionskontrolle) sollen getrennt gebaut werden. Dafür brauchen sie eine Build-Reihenfolge. In welche Richtung dürfen die Module voneinander abhängen, was bedeutet ein Pfeil im Diagramm, und welches Modul spricht mit welchem externen System: Rechnungswesen, SMS und E-Mail, Kasse, Online-Payment, Webshop?

Eberhard zeichnet die Pfeile zunächst als Aufrufrichtung mit der ausgetauschten Information (50:58): Termin von Terminplanung zu Reparatur durchführen, Preis von Reparatur durchführen zu Bezahlung, Materialbestellung von Reparatur durchführen zu Materialbeschaffung. Der Chat fragt, ob damit synchrone Aufrufe festgelegt und Messages ausgeschlossen seien (55:59). Er verschiebt die Frage auf die technische Ebene und deutet die Pfeile um: Sie zeigen den Informationsfluss (58:17).

Dann schließt er die externen Systeme aus dem Kontextdiagramm an. Bei Rechnungswesen liegt die Wahl zwischen Bezahlung, das den Geldbetrag kennt, und Reparatur durchführen, das die Positionen kennt (ADR-009: Fachlicher Modulschnitt statt technischer Schichten). Der Chat schlägt zusätzlich "Bezahlung, Rechnungswesen, Rechnung ist bezahlt" vor (63:16).

Betroffene Qualitätsszenarien: Keines direkt. Die Richtung der Abhängigkeiten dient der Baubarkeit, nicht einem Qualitätsszenario. Die spätere Wahl zwischen synchronen Aufrufen und Messages (R-034) wird die Zuverlässigkeitsszenarien berühren; welche, entscheidet erst diese Folgeentscheidung.

Option A: Ungerichtet, Zyklen erlaubt. Jedes Modul darf jedes andere nutzen. Vorteil: Rückfragen wie "ist die Planung noch okay?" sind ohne Umweg möglich. Nachteil: Keine Build-Reihenfolge; die Module lassen sich nur gemeinsam bauen.

Option B: Gerichteter Graph. Terminplanung nutzt Reparatur durchführen, Reparatur durchführen nutzt Bezahlung und Materialbeschaffung. Rechnungswesen hängt an Reparatur durchführen, SMS und E-Mail an Reparatur durchführen, Kasse und Online-Payment an Bezahlung. Vorteil: Bezahlung und Materialbeschaffung bauen zuerst, dann Reparatur durchführen, dann Terminplanung. Nachteil: Rückfragen gegen die Richtung brauchen einen anderen Mechanismus.

Option C: Gerichteter Graph, Rechnungswesen an Bezahlung. Wie B, aber das Rechnungswesen bekommt seine Daten von Bezahlung, weil dort die Zahlung stattfindet. Vorteil: Rechnung und Zahlung liegen an einer Stelle. Nachteil: Bezahlung kennt nur den Geldbetrag, die Rechnung braucht die Positionen.

Option B ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

B und C enden gleich. Den Ausschlag gibt der Informationsgehalt: Nur Reparatur durchführen weiß, was repariert wurde, und das gehört in die Rechnung. Ob die Zahlung das Rechnungswesen erreichen muss, bleibt offen.

Die Abhängigkeiten bilden einen gerichteten Graphen: Terminplanung nutzt Reparatur durchführen, Reparatur durchführen nutzt Bezahlung und Materialbeschaffung. Ein Pfeil bedeutet Informationsfluss mit der ausgetauschten Information, nicht Aufrufrichtung. Extern gilt: Rechnungswesen bekommt Rechnungselemente von Reparatur durchführen; SMS und E-Mail bekommen Informationen über Updates von Reparatur durchführen; Kasse und Online-Payment hängen an Bezahlung. Terminplanung, Reparatur durchführen und Bezahlung liefern je eigene Seiten in den Webshop; Webshop und User-Datenbank gelten dabei als eine Einheit. Materialbeschaffung hat keine Seite im Webshop. Ob Bezahlung dem Rechnungswesen die Zahlung meldet, ist nicht entschieden.

Die Richtung dient dem Bauen. Eberhard: "ich möchte gerne, dass tatsächlich Materialbeschaffung und Bezahlung gebaut werden können" (57:15), "Reparatur das irgendwie nutzt und Terminplanung das irgendwie nutzt" (57:21). Eine Build-Reihenfolge "kann ich ja nur dann haben, wenn eben die technischen Abhängigkeiten in diese eine Richtung gehen" (57:30). Er sieht sofort den Preis: "dass die Terminplanung vielleicht bei der Reparatur nachfragen muss, ob die aktuelle Planung noch okay ist" (57:50).

Die Pfeilsemantik ändert er auf Nachfrage. Er gibt zu: "Tatsächlich ist es so, dass ich über synchrone Calls nachgedacht hatte" (56:12), "ein bisschen war da ein synchrones Denken bei" (56:51). Messages seien ebenso möglich (56:38). Er entscheidet das nicht: "Wir sind auf der konzeptionellen Ebene" (57:07). Den Vorschlag, die Pfeile als Informationsfluss zu lesen, nimmt er an: "Ja, vielleicht ist das besser" (58:21), "Lass uns sagen, es gibt einen Informationsfluss" (58:25).

Bei den externen Systemen entscheidet der Informationsgehalt. SMS und E-Mail dienen dazu, "dass ich Updates schicke über den Zustand der Reparatur" (60:13), also nutzt sie Reparatur durchführen. Kasse und Online-Payment werden "offensichtlich genutzt von der Bezahlung" (60:44). Das Rechnungswesen hängt er an Reparatur durchführen, "weil ich hier ja eben die Information habe, was genau repariert worden ist" (61:17), "und das will ich in der Rechnung drin haben" (61:25). Bezahlung weiß nur: "ich habe irgendwie 250 Euro bezahlt" (61:30). "Deswegen sind das eben unterschiedliche Informationen" (61:33). Für den Webshop gilt: Seiten einblenden, "die es mir zum Beispiel ermöglichen, Reparaturen zu schedulen" (62:23), den Reparaturstand zu sehen und zu bezahlen, also aus drei Modulen (62:46).

Jans Vorschlag "Rechnung ist bezahlt" lässt er offen: "Weiß ich nicht. Ist das so?" (63:23). Das könne "auch eher im Hintergrund laufen zwischen Kasse, Online-Payment und dem Rechnungswesen" (63:25).

Positiv

Negativ

Risiken

Das Reparatursystem muss irgendwo laufen. Der Fahrradshop beschäftigt keine IT-Experten, verlangt aber 99 % Verfügbarkeit zwischen 9 und 18 Uhr und einen Wiederanlauf in 30 Minuten. Wo betreiben wir das System: im Laden, in einem Rechenzentrum oder in der Cloud, und bei welchem Anbieter?

Folge 113 setzt die Qualitätsszenarien aus Folge 111 in Maßnahmen um. Eberhard liest die Szenarien der Reihe nach vom Board und fragt bei jedem, ob er eine Antwort hat. Das Szenario "Im Shop sind keine IT-Experten beschäftigt" (05:36) ist das erste, das eine Infrastrukturentscheidung erzwingt. Es hängt "mit ein paar anderen Szenarien zusammen" (06:13): Verfügbarkeit und Wiederanlauf.

Die Wahl fällt früh und zieht die restliche Folge nach sich: das Deployment (ADR-014: Monolith oder Microservices bleibt offen, ADR-015: Mindestens zwei Instanzen über mehrere Availability Zones), die Datenbank (ADR-016: Relationale Datenbank als Managed Service (RDS)) und der Support (ADR-017: Eigener Support mit Rufbereitschaft statt Betrieb durch den Shop) setzen alle die Cloud voraus. Bei 37:34 prüft Eberhard die Entscheidung noch einmal gegen die Alternativen, nachdem er die AWS-SLAs gelesen hat.

Betroffene Qualitätsszenarien: QS-U-07 ist der Auslöser: kein Betrieb ohne IT-Experten mit einem Server vor Ort. QS-Z-01, QS-Z-02 und QS-Z-04 liefern die Zahlen, an denen ein Server im Laden scheitert. QS-A-01 ist mittelbar betroffen: Eine SaaS-Lösung setzt einen zentralen Betrieb voraus, den ein Server je Laden nicht bietet.

Option A: Server im Laden. Ein Rechner steht im Fahrradshop, das Team installiert und wartet ihn. Vorteil: Keine Abhängigkeit vom Internet für den Betrieb im Laden. Nachteil: Niemand vor Ort kann den Server betreuen; ein Wiederanlauf in 30 Minuten setzt voraus, dass jemand hinfährt.

Option B: Externes Rechenzentrum oder Hosting. Das System läuft auf gemieteter oder eigener Hardware in einem Rechenzentrum. Vorteil: Volle Kontrolle über die Umgebung. Nachteil: Eberhard erwartet höhere Kosten ohne Gewinn an Verfügbarkeit.

Option C: Cloud bei AWS. Das System läuft auf Amazon Web Services, mit EC2 oder EKS, RDS und weiteren Managed Services. Vorteil: Verfügbarkeitsgarantien im SLA, kein eigener Betrieb der Hardware, dem Autor vertraut. Nachteil: Bei SLA-Verletzung gibt es nur eine Gutschrift, der wirtschaftliche Schaden bleibt beim Shop.

Option D: Andere Cloud. Google Cloud oder Microsoft Azure statt AWS. Vorteil: Ein Team mit anderer Erfahrung arbeitet dort schneller. Nachteil: Nach Eberhards Einschätzung dasselbe ökonomische Modell wie AWS; kein Anbieter haftet für Ausfälle.

Option C ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

Option A scheitert an drei Szenarien zugleich. Option B verliert bei den Kosten und gewinnt nirgends. Option D ist gleichwertig; die Wahl zwischen C und D ist Gewohnheit, keine Architektur.

Wir betreiben das Reparatursystem in der Cloud bei AWS. Es steht kein Server im Laden. Der Anbieter AWS ist eine Wahl aus Vertrautheit; ein Team, das Google oder Microsoft besser kennt, darf tauschen, solange das Betriebsmodell gleich bleibt.

Der Server im Laden fällt zuerst. Eberhard leitet aus dem Szenario ab, "dass wir eigentlich nicht ernsthaft einen Server unterstellen können" (06:01). Der Wiederanlauf macht es endgültig: "Ich schaffe es nicht, innerhalb von 30 Minuten vor Ort zu sein" (06:36), also "das können wir eigentlich schon mal irgendwie ausschließen" (06:44). Bei 09:14 wiederholt er: "einen Server in dem Laden selber ausschließen können".

Die Cloud ist die Antwort, nicht die einzige denkbare: "meine Lösungsstrategie wäre halt irgendwie Cloud" (08:38), aber "es könnte ja auch sein, dass wir in einem externen Rechenzentrum das machen" (09:10). Er verfolgt das Rechenzentrum nicht weiter. Bei 38:04 nennt er es "wahrscheinlich teurer" und ist "nicht sicher, ob das wirklich eine höhere Verfügbarkeit erzeugt" (38:10). Für den Server beim Händler gilt dasselbe (38:15).

Die anderen Clouds prüft er nach der SLA-Lektüre: "ich benutze Google und Microsoft, wäre eine Alternative" (37:40). Ein Modell, in dem der Anbieter "für Schadensersatz gerade steht, kann eigentlich nicht funktionieren" (37:55); die Alternativen helfen also nicht. Das Fazit: "vielleicht ist das hier tatsächlich die beste Lösung" (38:21). AWS bleibt Gewohnheit: "ich kenne irgendwie Amazon" (53:15), Google wäre "irgendwie auch fein" (53:19). Die Wahl ist kommerziell begründet: "wenn sozusagen mein Leben davon abhängt" (38:30), würde er "vielleicht etwas anders vorgehen" (38:39). DSGVO ist geprüft: "in der Amazon Cloud irgendwie machbar" (43:45), "kein Killer-Argument" (43:48).

Eberhards Einwand zum Format. Jan fragt im Chat, ob die Abwägung Server gegen Cloud als ADR festzuhalten wäre (42:09). Eberhard findet ADRs "prinzipiell auch eine gute Idee" (42:39), würde sie hier aber nicht nehmen: Sein Problem sei, "dass die das Potenzial haben, einfach unstrukturiert irgendwelche Entscheidungen zu enthalten" (42:48). Hier gehe es um "die Kernentscheidung des Systems" (42:57), "das wäre für mich eher eine Solution Strategy" (43:02). Die Abwägung selbst hält er für unverzichtbar: "nochmal die Abwägung hinzuschreiben, das ist, glaube ich, eine sehr, sehr wichtige" (43:05). Wenn festgehalten ist, "was mich zu dieser Meinung bewegt, dann kann man darüber diskutieren" (43:34). Dieses ADR widerspricht ihm im Format und folgt ihm in der Sache: Die Abwägung steht hier, Kapitel 4 verweist darauf.

Positiv

Negativ

Risiken

Die vier fachlichen Module aus ADR-009: Fachlicher Modulschnitt statt technischer Schichten müssen auf die Infrastruktur aus ADR-013: Betrieb in der Cloud bei AWS statt Server im Laden. Deployen wir sie zusammen als einen Monolithen auf einer virtuellen Maschine oder getrennt als Container je Modul? Und müssen wir das jetzt entscheiden?

Eberhard zeichnet in Folge 113 zwei Deployment-Diagramme mit eigener Legende. Das erste: "das gesamte Ding wird halt monolithisch deployed als beispielsweise eine EC2 Instanz" (17:40). Das zweite: "ich habe ein Container, in dem die Terminplanung läuft" (19:28), und so weiter für alle vier Module, was "so was wie EKS benutze, also ein Kubernetes Service" (19:44) voraussetzt. Beide Diagramme bleiben am Board stehen.

Die Frage berührt ADR-011: Jede Komponente ist ein eigenes Projekt in der Versionskontrolle: Dort hat jedes Modul ein eigenes Repository, "ein oder mehrere Projekte in der Versionskontrolle" (20:12) sind bei Containern "irgendwie egal" (20:17). Die roten Boxen der Bausteinsicht ändern mit der Wahl ihre Bedeutung: Projekte im Monolithen, "Docker Images" (20:01) bei Containern. ADR-012: Gerichtete Abhängigkeiten und Zuordnung der externen Systeme zur Integration der Module bleibt von der Wahl unberührt.

Betroffene Qualitätsszenarien: Keines, und das ist der Kern dieser Entscheidung. Eberhard prüft QS-Z-01 bis QS-Z-06 und findet keinen Unterschied zwischen den Varianten. Nur QS-Z-03 (Preis nach 2 Minuten) sieht er als leichten Vorteil der Container, verwirft den Vorteil aber, weil er dem Wiederanlauf nicht hilft.

Option A: Monolith auf EC2. Alle vier Module laufen in einem Deployment auf virtuellen Maschinen. Vorteil: Ein Artefakt, ein Deployment, keine Netzwerklatenz zwischen Modulen. Nachteil: Multi-AZ braucht einen Elastic Load Balancer und mindestens zwei Instanzen von Hand (ADR-015: Mindestens zwei Instanzen über mehrere Availability Zones).

Option B: Microservices auf EKS. Jedes Modul läuft als eigener Container in einem Kubernetes-Cluster. Vorteil: Der Bezahlungscontainer kann höher redundant laufen als die anderen; EKS verteilt Container selbst über Availability Zones. Nachteil: Mehr Infrastruktur, Latenz zwischen Containern, vier Docker Images statt einem Artefakt.

Option C: Serverless. Die Module laufen als Funktionen (Lambda, Azure Functions), bezahlt wird nur aktive Rechenzeit. Vorteil: Eine Instanz je Shop wird billig, was die Mandantenfrage entspannt. Nachteil: Im Video nur als Kostenoption genannt, nicht als Deployment des Kernsystems entworfen.

Option A ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

Die Matrix bestätigt Eberhards Urteil: Zwischen A und B liegt ein Punkt, und der stammt aus Kriterien, die kein Qualitätsszenario verlangt. Option C hat zu viele offene Zellen, um sie zu bewerten.

Wir entscheiden nicht. Beide Deployment-Diagramme bleiben gültig, Monolith auf EC2 und Container auf EKS. Die Entscheidung fällt mit dem ersten Inkrement, wenn das Team steht und seine Gewohnheiten kennt. Serverless bleibt eine Kostenoption für den Fall, dass der Shop eine Instanz je Mandant statt Mandantenfähigkeit wählt.

Eberhard stellt die Frage selbst: "Also ist das eine relevante Architekturentscheidung?" (20:29). Seine Antwort: In Bezug auf die Qualitätsszenarien "hat das keinen Einfluss" (20:32), denn "das eine wie das andere bekomme ich halt irgendwie genauso verfügbar" (20:38). Das Fazit ist eindeutig: "die Frage Microservices oder nicht, halte ich hierfür relativ irrelevant" (21:37).

Den einzigen Vorteil der Container prüft er und verwirft ihn. "Der Bezahlungscontainer, der wird halt redundanter ausgelegt" (21:13), etwa "fünf Instanzen" (22:20) statt "von den anderen nur zwei" (22:23). Das bringt "einen leichten Vorteil in Bezug auf die Verfügbarkeit bei der Bezahlung" (22:26). "Aber das hilft mir nichts bei dem Wiederanlauf, was ja eigentlich das wesentliche Kriterium ist" (22:31). Redundanz "hilft ja nur gegen Ausfallsicherheit" (22:45). Jans Einwand im Chat stützt die Gleichwertigkeit: Die Latenz zwischen Containern sei gegenüber der Latenz zwischen Laden und Rechenzentrum "zweitrangig" (21:50).

Serverless kommt erst bei der Mandantenfrage auf: "vielleicht ist das dann auch sogar kostengünstig machbar" (50:49), weil man nur die Instanzen bezahlt, die aktiv sind (50:55). Dieter ergänzt im Chat "Lambda, Azure Functions wäre eine weitere Möglichkeit" (56:21). Ein Deployment-Diagramm dafür zeichnet Eberhard nicht.

Der Aufschub ist Methode, nicht Verlegenheit. Eberhard fokussiert sich "auf die Themen, von denen ich eben erwarte, dass sie sozusagen spannend sind" (16:30), und hält es für wichtiger, "die wichtigen Punkte identifiziert" (54:41) zu haben, als viele beliebige Entscheidungen zu treffen (54:41 bis 55:03, sinngemäß).

Positiv

Negativ

Risiken

Das System läuft bei AWS (ADR-013: Betrieb in der Cloud bei AWS statt Server im Laden). Reicht eine Instanz, wie das erste Deployment-Diagramm sie zeigt, um 99 % Verfügbarkeit zwischen 9 und 18 Uhr und 99,9 % im Web zu erreichen? Oder verlangt das SLA des Anbieters mehr Instanzen?

Eberhard rechnet das Werkstatt-Szenario zuerst grob durch: 99 % von 9 Stunden sind "3 Minuten" (30:53) Ausfall am Tag, "prinzipiell erstmal machbar" (30:55). Weil Verfügbarkeit "eines der wenigen Qualitätsszenarien, was ich habe" (31:00) ist, liest er die AWS-SLAs für EC2 und EKS nach. Er sagt Amazon, "weil das irgendwie die Cloud ist, über die ich am meisten weiß" (31:31), und nimmt an, dass es "in anderen Clouds ähnlich sein wird" (31:39).

Das Board zeigt auf Seite 10 noch "einer EC2-Instanz". Das Transkript ist weiter: Schon bei 18:12 kündigt Eberhard an, "dazu kommen wir gleich irgendwie mehrere". Diese Entscheidung gilt für beide Deployment-Varianten aus ADR-014: Monolith oder Microservices bleibt offen.

Betroffene Qualitätsszenarien: QS-Z-01 (99 % Werkstatt) ist der Auslöser der SLA-Lektüre. QS-Z-04 (99,9 % Web) verlangt das Zehnfache und setzt die Maßnahme erst recht voraus. QS-Z-02 und QS-Z-05 tragen dieselbe Maßnahmen-Karte "EKS / EC2 SLAs" auf dem Board; Eberhard nennt sie bei 39:18 bis 39:49 als seine Antwort auf alle Verfügbarkeits- und Wiederanlauf-Szenarien.

Option A: Eine EC2-Instanz. Der Monolith läuft auf einer einzigen virtuellen Maschine, wie auf Board Seite 10 gezeichnet. Vorteil: Billigste und einfachste Konfiguration. Nachteil: Der Ausfall einer Availability Zone nimmt das System mit, und dieser Ausfall zählt laut SLA nicht einmal als Ausfall.

Option B: Mindestens zwei Instanzen über mehrere Availability Zones. Bei EC2 stehen mindestens zwei Instanzen in verschiedenen Zonen hinter einem Elastic Load Balancer; bei EKS laufen mehrere Container-Instanzen, die der Cluster selbst verteilt. Vorteil: Erst diese Konfiguration bringt das System in den Geltungsbereich des SLA. Nachteil: Doppelte Instanzkosten, ein Load Balancer, und der Zustand darf nicht auf einer Instanz liegen.

Option B ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

Option A gewinnt bei Kosten und Aufwand und verliert bei allem, was die Szenarien verlangen. Bei EKS entfällt sogar der Aufwandsvorteil.

Das System läuft auf mindestens zwei Instanzen, verteilt über mehrere Availability Zones einer Region. Bei EC2 heißt das: ein Elastic Load Balancer vor mindestens zwei Instanzen. Bei EKS heißt das: mehrere Container-Instanzen je Modul; die Verteilung übernimmt der Cluster. Das Deployment-Diagramm auf Board Seite 10 ist in diesem Punkt überholt.

Die Entscheidung folgt aus dem SLA-Text, nicht aus einer Vermutung. AWS garantiert "eine Verfügbarkeit von 99,99% im Monat" (31:54), "hört sich ja erstmal super an" (32:02). Die Definition dahinter ist der Punkt: "ein Ausfall einer Availability-Zone ist noch kein Ausfall" (32:21), "das ist ein juristischer Text" (32:25). Ein Ausfall liegt erst vor, wenn "mehr als eine Availability-Zone in der Region ausgefallen ist" (32:30).

Daraus liest Eberhard eine Anweisung des Anbieters: "du musst darauf vorbereitet sein, dass eine Availability-Zone ausfällt" (33:03). Also "müssen wir irgendwie unser System verteilen auf mehrere Availability-Zones" (33:19). Für EKS gilt: "macht das offensichtlich automatisch" (33:25), man braucht nur "mehrere Container-Instanzen" (33:31). Für EC2: "Elastic Load Balancer davor stecken" (33:35) und "mindestens zwei EC2-Instanzen" (33:39). Sein Fazit: "etwas sehr Konkretes, was sich ableitet aus unserer Verfügbarkeitsanforderung" (33:43).

Für die einzelne EC2-Instanz nennt er eine zweite Zahl aus dem SLA: "90 % Verfügbarkeit pro Stunde" (34:28). Diese Zahl ist Eberhards Lesart des SLA-Texts und in diesem Projekt unverifiziert; sie trägt die Entscheidung nicht, nur der Hinweis dahinter: "nimm mal mindestens zwei EC2-Instanzen" (34:38).

Was das SLA nicht leistet, benennt er ebenfalls: Bei Unterschreitung gibt es "eine Gutschrift" (35:03), der Ausfall wird "trotzdem einen ökonomischen Schaden erzeugen" (35:19). Multi-AZ senkt die Wahrscheinlichkeit, ersetzt aber keine Haftung.

Positiv

Negativ

Risiken

Das Datenverlust-Szenario verlangt, dass nach einem Ausfall höchstens 5 Minuten an Daten fehlen, in 99,9 % der Fälle. Welche Datenbank erfüllt das, und wer betreibt sie: das Team selbst auf einer virtuellen Maschine oder der Cloud-Anbieter als Managed Service? Relational oder NoSQL?

Die Entscheidung ist die kürzeste der Folge. Eberhard liest die Karte als "dass Daten nicht verloren gehen sollen" (40:59), nennt die Zahlen 5 Minuten und 99,9 % nicht und antwortet mit einem Dienst: "im Amazon-Universum gibt es da RDS" (41:14), "der Datenbank-Service von denen" (41:22). Auf dem Board steht die Maßnahmen-Karte "RDS SLAs?" mit Fragezeichen.

Die Entscheidung setzt ADR-013: Betrieb in der Cloud bei AWS statt Server im Laden voraus und ergänzt ADR-015: Mindestens zwei Instanzen über mehrere Availability Zones: Was für die Anwendungsinstanzen gilt, muss für die Datenbank ebenfalls gelten, sonst nützt Multi-AZ nichts. Ob jedes Modul aus ADR-009: Fachlicher Modulschnitt statt technischer Schichten eine eigene Datenbank bekommt oder alle eine teilen, sagt das Video nicht.

Betroffene Qualitätsszenarien: QS-Z-07 ist der einzige Auslöser. Die Verfügbarkeitsszenarien QS-Z-01 und QS-Z-04 sind mittelbar betroffen, weil eine ausgefallene Datenbank das System mitnimmt; Eberhard stellt diesen Zusammenhang nicht her.

Option A: Selbst betriebene Datenbank auf EC2. Das Team installiert MySQL oder PostgreSQL auf eigenen Instanzen, richtet Replikation und Backups ein. Vorteil: Volle Kontrolle über Sicherung und Wiederherstellung, damit auch über das Datenverlust-Maß. Nachteil: Genau der Betriebsaufwand, den ADR-013: Betrieb in der Cloud bei AWS statt Server im Laden und ADR-017: Eigener Support mit Rufbereitschaft statt Betrieb durch den Shop vermeiden wollen.

Option B: RDS, relational. Amazon betreibt die Datenbank, wahlweise Oracle oder MySQL, mit Multi-AZ, automatischen Backups und Verfügbarkeitsgarantie. Vorteil: Kein eigener Datenbankbetrieb, SLA des Anbieters, vertraute Technik. Nachteil: Das SLA garantiert Verfügbarkeit, nicht den Datenverlust; das Maß von 5 Minuten muss das Team über Backup-Intervalle und Replikation selbst herstellen.

Option C: NoSQL-Dienst. DynamoDB oder ein vergleichbarer Dienst. Vorteil: Ebenfalls managed, horizontal skalierbar. Nachteil: Ungewohntes Modell für ein Team, das relationale Datenbanken kennt; das Domänenmodell mit Terminen, Protokollen und Rechnungen ist relational gut abbildbar.

Option B ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

Option A gewinnt nur beim Datenverlust-Maß und zahlt mit dem Betrieb. Option C bringt keinen Vorteil, den ein Szenario verlangt.

Die Daten des Reparatursystems liegen in einer relationalen Datenbank, die AWS als RDS betreibt. Die Engine ist Oracle oder MySQL; das Team wählt nach Gewohnheit. Die Datenbank läuft Multi-AZ, passend zu ADR-015: Mindestens zwei Instanzen über mehrere Availability Zones. Die RDS-SLAs sind vor dem ersten Inkrement gegen QS-Z-07 zu prüfen; die Karte behält bis dahin ihr Fragezeichen.

Eberhard wählt bewusst das Gewohnte: "einen Oracle oder MySQL, also ich bin da jetzt mal konservativ unterwegs" (41:24). NoSQL verwirft er in einem Satz: "ich will jetzt nicht irgendwie eine NoSQL-Datenbank oder sowas aufbauen" (41:29), sondern "einfach eine relationale Datenbank, so wie die meisten Projekte" (41:36). Ein Argument aus den Szenarien gibt er dafür nicht; die Wahl folgt demselben Muster wie Java und AWS (53:05 bis 53:19): das, womit das Team am besten umgeht.

Den Managed Service begründet er mit dem SLA, das er nur teilweise kennt: "muss man nochmal in die RDS-SLAs reingucken" (41:40). Nach seiner Recherche garantiere RDS "eine entsprechende Verfügbarkeit" (41:53), "so dass ich erwarten würde, dass das halt einfach funktioniert" (41:59). Dann die Einschränkung, die das Fragezeichen auf der Karte erklärt: "ich glaube aber, dass sie den Datenverlust eben tatsächlich nicht getrennt nochmal garantieren" (42:01).

Diese Lücke ist der Kern des ADR. Das Szenario misst Datenverlust, das SLA misst Verfügbarkeit. Der Weg von RDS zu höchstens 5 Minuten Verlust führt über synchrone Replikation in eine zweite Zone und über Backup-Intervalle, die das Team einstellt. Das Video benennt diesen Weg nicht; es benennt nur, dass er fehlt.

Positiv

Negativ

Risiken

Die Cloud (ADR-013: Betrieb in der Cloud bei AWS statt Server im Laden) nimmt dem Shop den Server ab, aber nicht den Betrieb. Wer installiert Updates, wer reagiert auf einen Ausfall, wer ist um zwei Uhr nachts erreichbar, wenn das Web-System steht? Der Shop hat keine IT-Experten; das Entwicklungsteam ist klein.

Eberhard kommt beim Sanity Check auf das Szenario "keine IT-Experten" zurück. Seine bisherige Antwort: "ich benutze die Cloud" (28:21), der Shop hat "nur eine Webadresse" (28:28). Dann fragt er nach: "reicht das eigentlich?" (28:42). Die Antwort ist nein, und daraus entstehen zwei Maßnahmen-Karten: "Eigener Support" bei den Werkstatt-Szenarien und "Eigener Support 24/7" beim Web-Szenario nachts.

Die Szenarien haben verschiedene Zeitfenster. Werkstatt: 9 bis 18 Uhr. Web: 7 bis 24 Uhr mit 99,9 % und 24 bis 7 Uhr mit 99 %. Die beiden Web-Fenster ergeben zusammen den ganzen Tag. Das bestimmt, wer den Support leisten kann.

Betroffene Qualitätsszenarien: QS-U-07 ist der Auslöser. QS-Z-01, QS-Z-02 und QS-Z-03 tragen die Karte "Eigener Support"; Eberhard nennt sie bei 38:59 bis 39:26 als seine Antwort auf Ausfall, 30 Minuten und 2 Minuten. QS-Z-04, QS-Z-05 und QS-Z-06 verlangen Rufbereitschaft rund um die Uhr (39:40 bis 39:49, 40:26).

Option A: Der Shop betreibt selbst. Das Team übergibt das System, der Shop kümmert sich um Updates und Störungen. Vorteil: Keine laufenden Kosten für das Team. Nachteil: Widerspricht QS-U-07 direkt; niemand im Shop kann das.

Option B: Support durch das Entwicklungsteam zu Bürozeiten. Eine Entwicklerin ist tagsüber erreichbar, installiert Updates und behebt Störungen. Vorteil: Deckt die Werkstatt-Szenarien 9 bis 18 Uhr mit vorhandenen Leuten. Nachteil: Nachts und am Wochenende ist niemand erreichbar; das Web-Szenario nachts bleibt ungedeckt.

Option C: Rufbereitschaft rund um die Uhr. Zusätzlich zu B ist jemand jederzeit erreichbar, der das System wieder in Gang bringt. Vorteil: Deckt alle Verfügbarkeits- und Wiederanlauf-Szenarien, auch das Web nachts. Nachteil: Rufbereitschaft kostet, und "das wird wahrscheinlich keine Entwicklerin sein" (40:54); es braucht Betriebspersonal oder einen Dienstleister.

Option C ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

Option A scheitert an fast allem. Option B reicht für die Werkstatt und fällt beim Web. Option C ist die einzige, die alle Szenarien deckt; ihr Preis ist der offene Punkt.

Das Entwicklungsteam leistet den Support, nicht der Shop. Tagsüber kümmert sich eine Entwicklerin um Updates, Störungen und Wiederanlauf; das deckt die Werkstatt-Szenarien. Für das Web-System gilt Rufbereitschaft rund um die Uhr durch eine Person, die kein Entwickler sein muss. Der Support muss telefonisch erreichbar sein.

Die Cloud allein reicht nicht, "weil es kann sein, dass irgendwelche Dinge ausfallen" (28:46). Außerdem muss jemand "Updates vielleicht installieren von irgendwelchen Dingen, weil es Security-Probleme gibt" (28:59). Also: "ich brauche schon irgendwie einen eigenen Support" (29:05). Eine neue Version einzuspielen sei etwas, "was man wahrscheinlich irgendwie EntwicklerInnen noch mit aufzwingen kann" (29:15); das ist "noch nicht so ein großes Problem" (29:24).

Bei 38:50 wird der Support zur Antwort auf die Verfügbarkeit: "ich brauche halt einen eigenen Support", der angerufen werden kann (38:54; Whisper transkribiert "daraus telefoniert werden kann"). "Die 30 Minuten sollten wir hoffentlich erreichen" (38:59). Dieselbe Antwort gilt "in Bezug auf die zwei Minuten" (39:18), "für die Verfügbarkeit im Web" (39:40) und "für den Wiederanlauf" (39:49).

Die Zeitfenster trennen die Besetzung. Für 9 bis 18 Uhr reicht "eine Entwicklerin, die sich um das Thema im Wesentlichen kümmern kann" (40:19). Beim Web "wird es dann schwierig" (40:26): 7 bis 24 und 24 bis 7 Uhr, "das ist also ein 24-7-Support" (40:35). "Ich brauche jemanden, der in Rufbereitschaft ist" (40:44), und das ist "ein ganz anderes Thema" (40:44): jemand, der "nachts um zwei sich rausklingeln lässt und das wird wahrscheinlich keine Entwicklerin sein" (40:49).

Positiv

Negativ

Risiken

Das System läuft in der Cloud (ADR-013: Betrieb in der Cloud bei AWS statt Server im Laden). Fällt im Laden der Router oder beim Provider die Leitung aus, ist das System für die Werkstatt weg, obwohl es in der Cloud läuft. Das Szenario "Preis nach spätestens 2 Minuten" gilt trotzdem. Was tun wir gegen einen Ausfall, den wir nicht verursachen und nicht beheben können?

Jan stellt die Frage im Chat, kurz nachdem Eberhard die Cloud gewählt hat: Fällt der Router im Laden aus, "eben das gesamte System ausfällt" (08:54) aus Sicht des Kunden. Eberhard nennt die Frage "eine spannende Sache" (09:28) und nutzt sie, um zu zeigen, wie man ein Qualitätsszenario liest, dessen Ursache außerhalb des eigenen Einflusses liegt. Betroffen sind "Ausfall eines Routers" (10:23) und Ausfall "des Internet-Providers" (10:25).

Das Szenario mit dem Preis ist "das aggressivste Wiederanlauf Kriterium, was wir irgendwie haben" (07:55). Aus Folge 112 gibt es dafür schon einen Low-Tech-Fallback: Preise auf Zettel oder in einer Tabelle, festgehalten in ADR-004: Bezahlung über externen Payment Service und Kasse im Laden und in Kapitel 8.5. Diese Entscheidung ergänzt ihn um die Frage, ob Technik im Laden den Ausfall abfangen soll.

Betroffene Qualitätsszenarien: QS-Z-03 (Preis nach 2 Minuten) ist der Auslöser; Eberhard liest es bei 10:06 vor. QS-Z-02 (Wiederanlauf 30 Minuten) ist betroffen, weil ein Cache-Server im Laden genau diese Frist nicht halten könnte (13:14).

Option A: Cache- oder Ersatzserver im Laden. Ein Rechner im Shop hält die Preise der Reparaturen vor und liefert sie bei Netzausfall. Vorteil: Der Preis ist auch ohne Internet abrufbar. Nachteil: Der Server muss gewartet werden, und ein Ausfall vor Ort bringt das 30-Minuten-Problem aus ADR-013: Betrieb in der Cloud bei AWS statt Server im Laden zurück.

Option B: Mobiler Router als Reserve. Neben dem festen Router steht ein LTE- oder 5G-Router, auf den das Netz im Laden automatisch umschaltet. Vorteil: Billig, keine Software, deckt den Ausfall des Festnetzanschlusses. Nachteil: Hilft nicht, wenn beide Wege oder der Provider im Stadtteil ausfallen.

Option C: Risiko akzeptieren. Der Shop nimmt in Kauf, dass bei Netzausfall im Laden das System nicht erreichbar ist, und greift auf den Low-Tech-Fallback zurück. Vorteil: Kostet nichts. Nachteil: QS-Z-03 ist in diesem Fall technisch nicht erfüllt; die Erfüllung hängt am Fallback aus ADR-004: Bezahlung über externen Payment Service und Kasse im Laden.

Option C ist die Referenz und steht auf 0. Zellen mit ? brauchen ein Urteil des Teams; das Video belegt sie nicht.

Option A kauft den Preis-Vorteil mit genau den Problemen, die die Cloud lösen sollte. Option B ist die einzige Verbesserung, die nichts zurückholt; sie ist die erwartete Ergänzung, keine Alternative zur Akzeptanz.

Der Netzausfall im Laden wird als Risiko akzeptiert. Es steht kein Cache- oder Ersatzserver im Shop. Das Team legt dem Kunden das Risiko mit Preisen für die Gegenmaßnahmen vor; erwartet wird, dass der Shop es akzeptiert und höchstens einen mobilen Router als Reserve einbaut. Für die Preisermittlung während eines Ausfalls gilt der Low-Tech-Fallback aus ADR-004: Bezahlung über externen Payment Service und Kasse im Laden.

Eberhard verwirft zuerst die bequeme Lesart: "Ist nicht mein Problem, was soll’s" (09:42). "Das finde ich nicht wirklich hilfreich" (09:45). Ein Qualitätsszenario sei "die Erwartungshaltung, die ein Kunde hat" (09:55); die Ursache des Ausfalls ändert daran nichts. Seine Aufgabe sei, "technisch zu bewerten, wie ich das umsetzen kann" (12:25), und "die variable Größe dabei ist Preis" (12:32).

Dann bepreist er die Optionen. Der mobile Router: "einen mobilen Router, der über LTE oder über 5G" (11:08) die Verbindung redundant hält, "kostet halt irgendwie einen Router und irgendwelche Netzwerktricks" (12:55), also "nicht so wahnsinnig teuer" (13:02). Der Cache-Server: Software "in deinem Server, den du nicht hast" (12:00), die die Preise cacht. "Das würde bedeuten, wir müssen den irgendwie warten" (13:12), und "wir müssen innerhalb von 30 Minuten da sein, sagst du" (13:14). "Das kostet also deutlich mehr Geld" (13:19). Selbst mit zwei Routern bleibt ein Rest: "wenn irgendwo in dem Stadtteil das Internet insgesamt von einem Provider ausfällt" (11:33).

Die Entscheidung überlässt er dem Kunden, mit einer klaren Erwartung: "das wäre jetzt etwas, was ich diskutieren würde, glaube ich, offen mit dem Kunden" (11:46). Die Frage "Wollen wir das tun?" (12:17) sei "ein valides Feedback" (12:19). Für einen Fahrradshop erwartet er, "dieses Risiko, dass die Verbindung zur Cloud abbricht, ist irgendwie akzeptabel" (13:36), "und vielleicht bauen wir dann noch einen mobilen Router als Fallback ein" (13:43). Anders wäre es bei "der Maschinensteuerung eines Atomkraftwerks" (13:47).

Positiv

Negativ

Risiken