Lösungsstrategie

Die Lösungsstrategie folgt der Rangfolge der Qualitätsziele aus Kapitel 1.2: zuerst Benutzerfreundlichkeit, dann Änderbarkeit Richtung SaaS, dann Verfügbarkeit. Security und Vertraulichkeit stehen bewusst weiter unten (Folge 111, 41:44 und 58:03). Alle Belege stammen aus den ADRs zu Folge 111 bis 113 und dem Miro-Board zum Endstand nach Folge 113. Folge 113 setzt die Qualitätsszenarien in Maßnahmen um: Für jedes Szenario soll es eine Antwort geben, "die ich geben kann, ohne rot zu werden" (58:04 bis 58:22).

Qualitätsziele und Lösungsansätze

Jedes Qualitätsziel aus Kapitel 1.2 hat einen benannten Ansatz.

Qualitätsziel Lösungsansatz Beleg

1. Benutzerfreundlichkeit für Kund:innen und Mitarbeitende

  • Kein zweites Konto: Login und Kundendaten (Adresse, Zahlungsart) kommen aus dem Webshop; das Reparatursystem liest das JWT-Cookie und fragt die REST-Schnittstelle der Webshop User Database ab.

  • Vorbelegtes Auftragsformular, damit 90 % der Kund:innen eine Reparatur in 2 Minuten beauftragen (QS-U-02).

  • Eigener Reparaturbereich unter /reparatur der Webshop-Domain statt Reparatur als Webshop-Produkt; der Ablauf folgt dem Reparaturprozess, nicht dem Kaufen und Abholen.

  • Eigene, vom Reparatursystem gerenderte Statusseite; der Status ist immer aktuell.

ADR-001, ADR-002, ADR-003, ADR-005; Board Seite 5

2. Änderbarkeit Richtung SaaS für andere Shops

  • Cloud-Betrieb, damit ohne IT-Experten im Shop betrieben werden kann und weitere Shops ohne neue Hardware dazukommen (Board Seite 6, Maßnahme "Cloud"; ADR-013). Für das SaaS-Szenario allein ist Cloud "extrem profan" und reicht nicht (Folge 113, 44:18).

  • Fachlicher Schnitt in vier Module entlang der Stories: Terminplanung, Reparatur durchführen, Materialbeschaffung, Bezahlung (Board Seite 7 und 9; ADR-009, ADR-010). Jedes Modul ist ein eigenes Projekt in der Versionskontrolle mit gerichteten Abhängigkeiten, damit die Module unabhängig gebaut werden können (ADR-011, ADR-012).

  • Mandantenfähigkeit von Anfang an, in Folge 113 entschieden (44:10 bis 47:02, 56:33 bis 57:43): Ein System ohne Rücksicht auf Mandanten in zwei Monaten mit 20 PT umzubauen hält Eberhard für "sehr unsicher" (44:50). Erwogene Alternativen: eine Instanz je Shop (Vorschlag von Zuschauer Jan, 50:09) und Serverless, damit die Instanz je Shop günstig wird (50:49). Den Trade-off Betriebskosten gegen Entwicklungskosten legt er dem Kunden vor (50:31 bis 50:47); der Breakeven hängt an der Mandantenzahl (57:33).

  • Skalierbarkeit auf zwei, drei oder zehn Shops sieht Eberhard als unkritisch, "nichts, worauf ich fokussieren würde" (47:02 bis 47:47). Offen bleibt der Umgang mit Kassen- und Rechnungssystemen anderer Shops (47:50 bis 48:44); erwartet ist eine Einschränkung auf bestimmte Systeme.

Board Seite 6, 7, 9; Änderungsszenario QS-A-01 (zwei Monate, 20 PT); Folge 112, 22:24 bis 48:16 und 54:13 bis 58:25; Folge 113, 44:10 bis 48:44 und 50:09 bis 57:43

3. Verfügbarkeit, differenziert nach Nutzergruppe

  • Differenzierte Ziele: Werkstatt 99 % zwischen 9 und 18 Uhr mit Wiederanlauf in 30 Minuten; Web 99,9 % zwischen 7 und 24 Uhr, nachts 99 %; Datenverlust höchstens 5 Minuten.

  • Betrieb bei AWS mit mindestens zwei Instanzen über mehrere Availability Zones hinter einem Elastic Load Balancer (ADR-015): Der AWS-SLA zählt einen Ausfall erst, wenn mehr als eine Availability Zone ausfällt (Folge 113, 32:30 bis 33:39). EKS verteilt Container automatisch, EC2 braucht dafür ELB und zwei Instanzen.

  • Relationale Datenbank als RDS mit Oracle oder MySQL (ADR-016) statt eigenem Datenbankbetrieb oder NoSQL; ob RDS den Datenverlust getrennt garantiert, bleibt das Fragezeichen auf der Karte (42:01).

  • Eigener Support mit Rufbereitschaft (ADR-017): für die Ladenzeiten eine Entwicklerin, für das Web-System rund um die Uhr (40:16 bis 40:59). Cloud allein reicht nicht, weil Ausfälle und Security-Updates jemanden brauchen, "der angerufen werden kann" (28:42 bis 29:24).

ADR-008, ADR-015, ADR-016, ADR-017; Board Seite 6 (Maßnahmen-Karten "EKS / EC2 SLAs", "RDS SLAs?", "Eigener Support"); Folge 113, 28:42 bis 42:09

Technologieentscheidungen

Entscheidung Begründung Beleg

REST für alle Integrationen nach außen (SMS Versand, EMail System, Kasse, Online Payment Service, Rechnungswesen, Webshop User Database)

Standardprotokoll, keine Sonderprotokolle; die gekauften Dienste bieten es ohnehin an.

Board Seite 3; ADR-004, ADR-007

JWT-Cookie des Webshops als Login-Mechanismus

Der Webshop stellt es nach dem Login aus; das Reparatursystem übernimmt es und baut keine eigene Nutzerverwaltung.

ADR-001

Pfad /reparatur unter der Webshop-Domain, Umleitung bestimmter URLs

Die Same-Origin-Policy lässt das Cookie nur innerhalb derselben Domain durch.

ADR-002

Externer Online Payment Service (in erster Linie PayPal): Redirect-Button im Frontend, REST-Statusabfrage im Backend; zusätzlich REST-Integration der Kasse im Laden

Keine Zahlungsdaten im eigenen System; Bezahlung bei Abholung bleibt im System sichtbar.

ADR-004

Gekaufter E-Mail-Dienst (Beispiel AWS Simple Email Service); SMS-Kanal vorgesehen, nicht gebaut

Dienst kaufen statt betreiben; E-Mail-Adresse liegt im Webshop-Konto vor.

ADR-007

AWS als Cloud-Anbieter: EC2 oder EKS für Rechenleistung, RDS für die Datenbank

In Folge 113 entschieden. AWS nur aus Vertrautheit: "ich kenne irgendwie Amazon", Google "wäre auch fein" (53:12 bis 53:19); Google und Microsoft haben "ein ähnliches ökonomisches Modell" (37:40). Die SLAs des Anbieters tragen die Verfügbarkeitsziele, weil der Shop keine IT-Experten hat.

Board Seite 6, 10, 11; ADR-008, ADR-013, ADR-015, ADR-016

Browser-Anwendung für alle Nutzergruppen

"Rechner nutzen das System über den Webbrowser" (Board Seite 10); Kund:innen kommen ohnehin aus dem Webshop.

Board Seite 10; ADR-003, ADR-005

Komponente = eigenes Projekt in der Versionskontrolle: vier Repositories, eines je Modul

Boxen im Diagramm brauchen eine Semantik, sonst "rede ich gerade über nichts". Die Alternative "Verzeichnis im Source Code" steht als Legende auf dem Board, ist aber nicht gewählt.

Folge 112, 54:13 und 63:39; ADR-011

Top-Level-Zerlegung

Das System zerfällt in vier fachliche Module, geschnitten entlang der Stories vom Board (Seite 7). Eberhard hat den Schnitt in Folge 112 hergeleitet (ADR-009):

  • Terminplanung: anmelden, Termin berechnen, Status abfragen, einplanen, Tagesplan, nächste Reparatur beginnen.

  • Reparatur durchführen: Defekt aufnehmen, Fahrrad abgeben und abholen, protokollieren, Kosten berechnen, Kund:in informieren.

  • Materialbeschaffung: Ersatzteile und Werkzeuge bestellen. Das Reparatursystem führt die Teile selbst, ohne Inventarsystem (ADR-006).

  • Bezahlung: Reparatur bezahlen, angebunden an Kasse und Online Payment Service.

Die Pfeile auf dem Board bedeuten Informationsfluss, nicht Aufrufrichtung (Folge 112, 58:17; ADR-012). Der Webshop blendet Seiten von Terminplanung, Reparatur durchführen und Bezahlung ein; Terminplanung liefert den Termin an Reparatur durchführen, Reparatur durchführen den Preis an Bezahlung und die Materialbestellung an Materialbeschaffung (Board Seite 9). Die technischen Abhängigkeiten bilden einen gerichteten Graphen in derselben Richtung, damit Bezahlung und Materialbeschaffung zuerst gebaut werden können, dann Reparatur durchführen, dann Terminplanung (Folge 112, 57:09). Details stehen in Kapitel 5.

Für das Deployment liegen zwei Varianten auf dem Board: alle vier Module in einem Artefakt auf EC2 (Deployment Monolith, Seite 10) oder jedes Modul in einem eigenen Container (Microservices, Seite 11). Die Entscheidung bleibt bewusst offen (ADR-014, Status Deferred): Für die Qualitätsziele hält Eberhard die Frage für "relativ irrelevant", beide Varianten bekommt er "genauso verfügbar" (Folge 113, 20:29 bis 21:37). Seit Folge 113 gilt für beide: mindestens zwei Instanzen über mehrere Availability Zones (ADR-015). Kapitel 7 beschreibt beide Varianten.

Organisatorische Leitlinie: kaufen statt bauen

Der Shop hat drei bis vier Mitarbeitende und keine IT-Experten (Folge 111, 16:51 und 54:06). Daraus folgt eine durchgängige Leitlinie: Bezahlung, E-Mail-Versand, Rechenleistung und Datenbank werden als Dienst gekauft, nicht selbst betrieben (ADR-004, ADR-007, Board Seite 5 und 6). Was das System selbst verantwortet, ist die Reparaturfachlichkeit einschließlich der Ersatzteile (ADR-006).

Eberhards Einwand zum ADR-Format

Zuschauer Jan fragt in Folge 113, ob die Abwägung Server gegen Cloud als ADR festzuhalten sei (42:09). Eberhard würde sie in der Lösungsstrategie festhalten, nicht als ADR: "Das sind so zentrale, die Kernentscheidung des Systems, das wäre für mich eher eine Solution Strategy" (43:02). Sein Vorbehalt gegen das Format: ADRs haben "das Potenzial, unstrukturiert irgendwelche Entscheidungen zu enthalten" (42:41). Die Abwägung selbst hält er für "sehr, sehr wichtig": Steht fest, was ihn zu seiner Meinung bewegt, "dann kann man darüber diskutieren" (43:26). Dieses Dokument nimmt beide Seiten des Einwands auf. Die Cloud-Abwägung steht hier in Kapitel 4 als Kernentscheidung und zugleich als ADR-013 mit Optionen und Pugh-Matrix, damit Kapitel 9 sie neben den übrigen Entscheidungen auffindbar und vergleichbar hält.

Offene Punkte

Die Zahl vier ist kein Kriterium. Eberhard gruppiert die Stories in Folge 112 induktiv, eine nach der anderen (23:03 bis 48:16); die vier Module sind das Ergebnis, nicht die Vorgabe. Das Kriterium für jeden Schnitt ist ein eigenes Domänenmodell mit eigenen Daten: Terminplanung und Reparatur durchführen haben "zwei unterschiedliche Informationsdichten" (33:21), Bezahlung kennt "nur noch einen Geldbetrag" (45:49). Drei Alternativen hat er erwogen und verworfen: die Aufteilung nach Schichten UI, Logik, Persistenz (22:24), ein fünftes Modul Reparaturstatus (35:03) und Bezahlung als Teil von Reparatur durchführen (45:41). Belege: ADR-009, ADR-010.

Die Entscheidung für den Cloud-Betrieb war in Folge 111 vertagt (59:33 bis 60:31: "es ergibt sich nicht direkt, welches Betriebsmodell angeraten ist"). Folge 113 trifft sie (06:01, 08:38, 38:25; ADR-013). Begründung: Der Shop hat keine IT-Experten, denen man einen Server im Laden anvertrauen könnte, und einen Wiederanlauf in 30 Minuten vor Ort "schaffe ich nicht" (06:30 bis 06:44). Eigenes Rechenzentrum und Server beim Händler wären teurer und nicht verfügbarer (38:04 bis 38:15); DSGVO in AWS ist "machbar, kein Killer-Argument" (43:39). Das Restrisiko eines Regionsausfalls nimmt Eberhard auf kommerzieller Basis in Kauf (35:03 bis 36:53, 38:39). Die Risiken R-010 und R-022 in Kapitel 11 bleiben: Die Anbindung von Kasse und Rechnungswesen aus der Cloud ist nicht entschieden und "kann im Extremfall die Lösungsstrategie zerstören" (24:38 bis 27:23; Kapitel 7).

Deployment Monolith oder Microservices bleibt bewusst offen (ADR-014, Status Deferred). Eberhard nennt die Frage in Folge 113 für die Qualitätsziele "relativ irrelevant" (20:29 bis 21:37). Ein eigener Container für Bezahlung könnte höher redundant laufen, "fünf Instanzen, die anderen nur zwei" (22:20); das hilft gegen Ausfall, nicht beim Wiederanlauf, "was das wesentliche Kriterium ist" (22:31 bis 22:45).

Note
 Offen: Die gelbe Notiz "ggf. finanziellen Aspekt separieren?" (Seite 9) deutet auf einen möglichen fünften Baustein hin. Sie fällt weder in Folge 112 noch in Folge 113, auch nicht sinngemäß; ihre Herkunft ist Vorbereitung oder Folge 114.