Das heißt, das kriegt man halt auch irgendwie hin. Und was ich jetzt hier identifiziert habe als ein Thema, ist … … ich hätte hier eine Kommunikation aus der Cloud hin zu der Kasse, die bei mir im Laden steht. Und da wäre halt … ich benutze mal irgendwie gelb … … eine Frage, kann man aus der Cloud in das Rechnungswesen kommunizieren? Und die analoge Frage wäre jetzt bei der Kasse. Also da wäre halt dieselbe Frage, kann man aus der Cloud in die Kasse kommunizieren? Und ich will das gar nicht ausschließen. Also was ich ja konkret machen müsste, wäre … … der Mensch sitzt halt an meinem System, sagt, diese Rechnung, das Ding will ich jetzt irgendwie gerne bezahlen. Und daraufhin gibt es eine Kommunikation hin zur Kasse, die sagt, ich möchte jetzt gerne das 20 Euro kassiert werden … … und die das halt irgendwie auch vernünftig in die Buchhaltung bekommt und so weiter und so weiter. Und dazu müsste ich halt mit diesem Kassensystem reden, aus der Cloud. Und vielleicht ist das möglich. Also das wäre jetzt die Stelle, wo man es halt recherchieren müsste. Kassensysteme sind heutzutage im Prinzip auch PCs, sodass ich das nicht ausschließen möchte, dass das geht. Aber das wäre etwas, was wir diskutieren müssten. Und das ist jetzt tatsächlich etwas, was wir sozusagen gelernt haben. Also was ich persönlich auch bei der Vorbereitung gelernt habe, als ich eben dieses Diagramm ausgeführt habe. Das heißt, das hat mir jetzt tatsächlich etwas geholfen. Also ich habe jetzt herausgefunden, dass ich hier potenziell etwas habe, was mir meinen Ansatz kaputt machen kann. Und das ist, glaube ich, die spannendere Sache. Die würde jetzt hier unten an der Luke gelten. Also, Moment. Jetzt habe ich bedauerlicherweise die Bausteine sich dafür torpediert. Also das wäre hier eben bei dem Microservices genau das selbe Thema. Da müsste ich also exakt dieselbe Frage beantworten. Das heißt, ich kann diese beiden Post-its da auch mal rüber kopieren, weil das wäre hier auch ein Thema. Das heißt, ich habe jetzt ein Risiko identifiziert und das ist auf jeden Fall hilfreich. Das kann mir im Extremfall die Lösungsstrategie zerstören. Ich kann nicht mit der Kasse kommunizieren. Ich kann nicht mit dem Rechnungswesen kommunizieren. Dann habe ich halt irgendwie ein Problem und da muss ich vielleicht doch ein Server installieren. Oder irgendwas auf dem Kassensystem machen oder was auch immer. Das ist dann eben das, womit ich mich da beschäftigen muss.
Randbedingungen
Die Randbedingungen stammen aus zwei Quellen: dem Gespräch in Folge 111 (Zeitmarken) und dem Endstand des Miro-Boards nach Folge 113 (Seitenangaben). Eberhard nennt die Webshop-Integration den wertvollsten Constraint, den das Kontextdiagramm sichtbar macht (28:22). Wo eine Randbedingung zu einer Entscheidung führte, verweist die Tabelle auf den ADR.
Technische Randbedingungen
| Randbedingung | Erläuterung | Quelle |
|---|---|---|
Bestehender Webshop als Fertigprodukt |
Der Shop betreibt einen Standard-Webshop für Kaufen und Abholen. Er ist nicht änderbar. Eine Reparatur als Produkt darin abzubilden wäre "unnatürlich, das ist etwas anderes". Das Reparatur-System ist deshalb ein eigener Bereich neben dem Webshop (ADR-003). |
|
Webshop User Database mit JWT-Cookie und REST |
Registrierung und Login bleiben im Webshop. Nach dem Login liefert der Webshop einen JWT als Cookie. Adresse und bevorzugte Zahlungsart liest das Reparatur-System per REST aus der User Database (ADR-001). Ein eigenes Registrierungs-Szenario ist damit "nicht erfüllbar". |
|
Same-Origin-Policy des Browsers |
Cookies gelten nur innerhalb derselben Domain. Das Reparatur-System muss deshalb unter der Webshop-Domain laufen; der Webshop leitet den Pfad |
29:32; Board Seite 3 |
Kasse im Laden |
Bezahlt wird typischerweise bei Abholung im Shop. Das Kassensystem ist "eine Art PC" im Laden; Anbindung per REST (ADR-004). Die lokale Integration erschwert einen reinen Cloud-Betrieb. |
|
Rechnungswesen und Steuerberater:in |
Jede Reparatur muss "vernünftig verbucht" werden. Das Reparatur-System übergibt Rechnungselemente per REST an das Rechnungswesen. |
|
Online Payment Service |
Online-Zahlung läuft über einen externen, PayPal-artigen Dienst (Konto oder Kreditkarte). Anbindung per REST für den Buchungsstatus plus UI-Integration über einen Redirect-Button (ADR-004). |
|
Bedienung im Browser |
Alle Nutzergruppen bedienen das System über den Webbrowser. "Rechner nutzen das System über den Webbrowser." Der Webshop verlinkt auf die Komponenten. |
Board Seite 10 |
E-Mail und SMS als gekaufte Dienste |
Benachrichtigungen laufen über einen zugekauften Dienst wie AWS Simple Email Service, per REST. SMS ist vorgesehen (ADR-007). |
|
Note
|
Offen: Ob das System aus der Cloud heraus mit Kasse und Rechnungswesen kommunizieren kann, steht auf dem Board als offene Frage (Seiten 10 und 11). In Folge 113 als Risiko behandelt, nicht entschieden (24:38 bis 27:23): Eberhard erkennt beim Zeichnen des Deployments, dass diese Anbindung "im Extremfall die Lösungsstrategie zerstören" kann, und will sie recherchieren. Genannte Optionen: direkt REST, Kassenproxy im Laden (Vorschlag von Zuschauer Jan, 29:27), Server im Laden, Änderung am Kassensystem (Kapitel 7, ADR-004). |
Transkript Folge 113, 24:38 bis 27:23
Organisatorische Randbedingungen
| Randbedingung | Erläuterung | Quelle |
|---|---|---|
Keine IT-Experten im Shop |
Die Mitarbeitenden haben "keine echte Ahnung von IT". Es gibt keinen Betrieb, deshalb ist der Betrieb kein Akteur. Das System muss ohne eigenes IT-Personal laufen. Folge 113 zieht daraus zwei Folgerungen: Betrieb in der Cloud (ADR-013), weil niemand im Laden einen Server installieren oder auf einen Alarm reagieren kann (05:47 bis 05:57), und ein eigener Support mit Rufbereitschaft (ADR-017), weil Cloud allein nicht reicht: Ausfälle und Security-Updates brauchen jemanden, "der angerufen werden kann" (28:42 bis 29:24, 38:50). |
16:59, 17:05, 17:09; Board Seite 5; Folge 113, 05:36 bis 06:13 und 28:42 bis 29:24 |
Kleiner Betrieb |
Ein lokaler Fahrradshop in Kaiserslautern mit drei bis vier Leuten. Ob eine eigene Installation pro Shop finanzierbar ist, ist offen und entscheidet über die SaaS-Architektur. |
|
Anforderungen liegen als Backlog vor |
Es gibt kein Anforderungsdokument, nur Stories auf dem Miro-Board. Der Architekt nimmt das Backlog als Input; fachliche Detaillierung liegt beim Requirements Engineering. |
|
Fachexperte ist imaginär |
Gespräche mit Anforderern und Experten werden nicht geführt, sondern angenommen und dokumentiert. |
|
Ein Architekt entwirft allein, der Chat ist Sparringspartner |
Eberhard Wolff entwirft live. Der Chat liefert Hinweise, die er übernimmt: Rechnungswesen (20:35), Same-Origin-Policy (29:32), Frage nach dem Betrieb als Akteur (16:22), Mandantenfähigkeit (43:58). |
Folge 111 durchgehend |
Zeitrahmen der Kata |
Drei Live-Folgen zu je rund einer Stunde. Das Ergebnis ist ein Miro-Board mit 11 Seiten, keine Implementierung. |
Board Seite 1 bis 11 |
Konventionen
Die ersten beiden Konventionen stammen aus dem Video. Die übrigen setzt dieses Repository für die nachträgliche Dokumentation.
| Konvention | Erläuterung | Quelle |
|---|---|---|
arc42 als Ablagestruktur, nicht als Vorgehensreihenfolge |
"Man sollte nicht blind so ein arc42-Template ausfüllen." Die Kapitel dienen zum Ablegen von Informationen; die Reihenfolge der Bearbeitung wählt der Architekt selbst. |
|
Qualitätsziele als Qualitätsszenarien mit Metrik und Perzentil |
Stimulus (Usage, Change, Failure) trifft auf das System, das Ergebnis ist eine Metrik. Adjektive wie "benutzerfreundlich" genügen nicht; Szenarien nennen Perzentile und Zeiten. |
|
Architekturentscheidungen als ADRs nach Nygard mit Pugh-Matrix |
Jede Entscheidung mit mehr als einer ernsthaften Option erhält einen ADR (Kontext, Optionen, Entscheidung, Konsequenzen) mit 3-Punkt-Pugh-Matrix. Stand: ADR-001 bis ADR-018. |
|
Docs-as-Code mit docToolchain |
AsciiDoc, PlantUML inline, Build über den |
Repository-Wurzel |
Sprache und Stil |
Deutsch, Fachbegriffe bleiben englisch. Zeitmarken im Format mm:ss beziehen sich auf Folge 111, sofern nicht anders angegeben. |
Dieses Dokument |
Folge 111 auf software-architektur.tv und Video auf YouTube. Die Zeitmarken im Text springen im Player an die Stelle. Audio: software-architektur.tv (Eberhard Wolff, Ralf D. Müller), Lizenz CC BY 4.0; für genaues Springen mit konstanter Bitrate neu kodiert.
Folge 113 auf software-architektur.tv und Video auf YouTube. Die Zeitmarken im Text springen im Player an die Stelle. Audio: software-architektur.tv (Eberhard Wolff, Ralf D. Müller), Lizenz CC BY 4.0; für genaues Springen mit konstanter Bitrate neu kodiert.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.