Bausteinsicht

Die Bausteinsicht folgt Seite 9 des Miro-Boards (Endstand nach Folge 113). Eberhard Wolff zerlegt das Reparatur-System dort in vier fachliche Bausteine. Die Zuordnung der Stories und die Beispieldaten stammen von Seite 7. Die Herleitung des Schnitts stammt aus Folge 112 (ADR-009, ADR-010, ADR-011, ADR-012). Code gibt es nicht; jede Aussage in diesem Kapitel stützt sich auf das Board und auf das Transkript zu Folge 112.

Whitebox Gesamtsystem

Das folgende C4-Container-Diagramm zeigt das Reparatur-System als Whitebox. Innerhalb der Systemgrenze liegen die vier Bausteine. Außerhalb stehen dieselben sieben externen Systeme wie im Kontext in Kapitel 3. Pfeile bedeuten Informationsfluss und nennen die ausgetauschte Information. Die Board-Legende sagt noch "Aufrufrichtung"; Eberhard hat die Semantik in Folge 112 auf eine Frage aus dem Chat zu Informationsfluss umdefiniert (58:17, ADR-012). Ob die Module sich synchron aufrufen oder Messages austauschen, bleibt auf dieser Ebene offen (57:01).

05 level1
Begründung

Die Zerlegung folgt den Stories aus dem Backlog (Board Seite 1). Eberhard gruppiert die Stories nach fachlichem Zusammenhang und gibt jeder Gruppe Beispieldaten (Board Seite 7). Das Ergebnis sind vier Bausteine entlang des Reparaturprozesses: Termin vereinbaren, Reparatur ausführen, Material besorgen, Geld einnehmen. Eine technische Schichtung (UI, Logik, Persistenz) verwirft Eberhard in Folge 112 ausdrücklich: Schichten sind "auf dieser grob-granularen Ebene nicht hilfreich" (22:24, ADR-009). Kriterium für jeden Schnitt ist ein eigenes Domänenmodell mit eigenen Daten (33:21).

Enthaltene Bausteine
Baustein Verantwortung

Terminplanung

Nimmt Reparaturen an, berechnet Termine, erstellt den Tagesplan und zeigt den Status.

Reparatur durchführen

Nimmt den Defekt auf, protokolliert Arbeit und Teile, berechnet Kosten, wickelt Abgabe und Abholung ab, informiert Kund:innen.

Materialbeschaffung

Bestellt Ersatzteile und Werkzeuge beim Großhändler.

Bezahlung

Nimmt den Geldbetrag für eine Reparatur über Kasse oder Online Payment Service entgegen.
Wichtige Schnittstellen

Das Board beschriftet vier interne Informationsflüsse: "Termin" (Terminplanung an Reparatur durchführen), "Preis" (Reparatur durchführen an Bezahlung), "Materialbestellung" (Reparatur durchführen an Materialbeschaffung) und nach außen "Rechnungselemente" (an Rechnungswesen) sowie "Info über Updates" (an SMS Versand und EMail System). Der Webshop ruft Terminplanung, Reparatur durchführen und Bezahlung über die Umleitung von /reparatur auf (ADR-002). Protokolle und Datenformate der internen Aufrufe legt das Board nicht fest. Die technischen Abhängigkeiten bilden einen gerichteten Graphen: Terminplanung nutzt Reparatur durchführen, Reparatur durchführen nutzt Bezahlung und Materialbeschaffung. So lassen sich Bezahlung und Materialbeschaffung zuerst bauen, dann Reparatur durchführen, dann Terminplanung (Folge 112, 57:09; ADR-012).

Offene Entwurfsfrage

Auf dem Board klebt eine gelbe Notiz: "ggf. finanziellen Aspekt separieren?". Gemeint ist, ob Preisermittlung, Rechnungselemente und Bezahlung in einen eigenen Baustein wandern, statt auf Reparatur durchführen und Bezahlung verteilt zu bleiben. Die Frage ist nicht entschieden; die Notiz stammt nicht aus Folge 112.

Komponentenbegriff

Jeder Baustein ist ein eigenes Projekt in der Versionskontrolle, also vier Repositories. Die Alternative "separiertes Verzeichnis im Source Code" steht auf dem Board als Legende, Eberhard hat sie in Folge 112 nicht gewählt (54:13, bestätigt 63:39; ADR-011).

Terminplanung

Zweck/Verantwortung

Terminplanung ist der Einstieg für Kund:innen und der Taktgeber der Werkstatt. Der Baustein nimmt Anmeldungen auf, berechnet den Reparaturtermin, plant Reparaturen ein und erstellt den täglichen Reparaturplan. Über ihn beginnt die Werkstatt die nächste Reparatur, und über ihn fragen Kund:innen den Status ab.

Schnittstellen

  • Eingehend: Webshop über Umleitung /reparatur (ADR-001, ADR-002); Kund:in und Mechaniker:in über den Browser.

  • Ausgehend: "Termin" an Reparatur durchführen.

Zugeordnete Stories (Board Seite 7)

  • Fahrrad zur Reparatur anmelden

  • Reparaturtermin berechnen

  • Status der Reparatur abfragen

  • Nächste Reparatur beginnen

  • Täglichen Reparaturplan erstellen

  • Reparatur einplanen

Beispieldaten (Board Seite 7)

"Reparatur 18.3. Eberhard"

Ablageort

Eigenes Projekt in der Versionskontrolle, siehe ADR-011 (Folge 112, 54:13). Code gibt es nicht.

Offene Punkte

Die Story "Status der Reparatur abfragen" steht auf dem Board bei Terminplanung und bei Reparatur durchführen. Folge 112 bestätigt das: Die Statusseite aus ADR-005 entsteht aus beiden Bausteinen, Terminplanung liefert den Termin, Reparatur durchführen den Protokollstand (32:21, 38:04); wer sie rendert, ist nicht gesagt. Kaufen statt bauen ist offen: Terminplanung ist generische Arbeitsplanung, "es steht außer Frage, dass man eine Terminplanung kaufen kann", bewertet hat Eberhard das nicht (43:58; ADR-010).

Reparatur durchführen

Zweck/Verantwortung

Reparatur durchführen ist der fachliche Kern. Der Baustein nimmt den Defekt auf, protokolliert jede Position mit Zeit und Preis, berechnet die voraussichtlichen Kosten und wickelt Abgabe und Abholung im Laden ab. Er stößt Materialbestellungen an, meldet den Preis an Bezahlung, liefert Rechnungselemente an das Rechnungswesen und informiert Kund:innen über Updates (ADR-007).

Schnittstellen

  • Eingehend: "Termin" von Terminplanung; Webshop über Umleitung /reparatur; Mechaniker:in und Shop-Mitarbeiter:in über den Browser.

  • Ausgehend: "Preis" an Bezahlung; "Materialbestellung" an Materialbeschaffung; "Rechnungselemente" an Rechnungswesen (REST); "Info über Updates" an SMS Versand und EMail System (REST).

Zugeordnete Stories (Board Seite 7)

  • Reparatur protokollieren

  • Status der Reparatur abfragen

  • Fahrrad zur Reparatur abgeben

  • Repariertes Fahrrad abholen

  • Fahrrad-Defekt aufnehmen

  • Voraussichtliche Kosten berechnen

  • Kunde über das Ende der Reparatur informieren

Beispieldaten (Board Seite 7)

Reparatur "Schaltung kaputt" mit Protokoll:

Position Dauer Preis

Neues Schaltwerk gekauft

100 €

Altes Schaltwerk ausgebaut

10 Minuten

10 €

Neues Schaltwerk eingebaut

10 Minuten

10 €

Bremsklötze

25 €

Bremsklötze einbauen

10 Minuten

10 €

Kunde informiert

0 €

Das Video nennt für die voraussichtlichen Kosten andere Zahlen: "Campagnolo-Schaltung", 200 Euro für das Schaltwerk, 20 Euro für die Montage (Folge 112, 28:06). Das Board hat als Endstand 100 € für das Schaltwerk; wir führen den Board-Stand.

Ablageort

Eigenes Projekt in der Versionskontrolle, siehe ADR-011 (Folge 112, 54:13). Code gibt es nicht.

Offene Punkte

Der Baustein trägt die meisten Schnittstellen nach außen. Die gelbe Notiz "ggf. finanziellen Aspekt separieren?" zielt auf Preis und Rechnungselemente in diesem Baustein; sie stammt nicht aus Folge 112. Der SMS Versand ist laut ADR-007 nur vorgesehen, nicht gebaut. Entwurfsnotiz: Ein fünftes Modul Reparaturstatus mit Kundensicht hat Eberhard in Folge 112 erwogen und verworfen (35:03 bis 37:22). Die Kundensicht braucht dieselben Daten wie das Protokoll, nur weniger davon; das rechtfertigt kein eigenes Domänenmodell (ADR-009).

Materialbeschaffung

Zweck/Verantwortung

Materialbeschaffung bestellt Ersatzteile und Werkzeuge beim Großhändler. Laut ADR-006 führt das Reparatur-System Teile und Bestände selbst; ein Warenwirtschaftssystem wird nicht angebunden.

Schnittstellen

  • Eingehend: "Materialbestellung" von Reparatur durchführen; Mechaniker:in über den Browser.

  • Ausgehend: keine auf dem Board. Der Großhändler ist kein externes System im Kontext; die Bestellung selbst zeigt das Board nicht als Schnittstelle.

Zugeordnete Stories (Board Seite 7)

  • Ersatzteile bestellen

  • Werkzeuge bestellen

Beispieldaten (Board Seite 7)

"Bestellung bei einem Großhändler"

Ablageort

Eigenes Projekt in der Versionskontrolle, siehe ADR-011 (Folge 112, 54:13). Code gibt es nicht.

Offene Punkte

NOTE: Offen: Ob die Bestellung beim Großhändler per Hand, per E-Mail oder über eine Schnittstelle läuft, sagt das Board nicht.

Bezahlung

Zweck/Verantwortung

Bezahlung nimmt den Geldbetrag für eine Reparatur entgegen. Zwei Wege sind vorgesehen (ADR-004): im Laden über die Kasse, online über den Online Payment Service mit Redirect-Button und REST-Statusabfrage.

Schnittstellen

  • Eingehend: "Preis" von Reparatur durchführen; Webshop über Umleitung /reparatur; Shop-Mitarbeiter:in und Kund:in über den Browser.

  • Ausgehend: Kasse (REST); Online Payment Service (REST und UI-Integration per Redirect-Button).

Zugeordnete Stories (Board Seite 7)

  • Reparatur bezahlen

Beispieldaten (Board Seite 7)

"Geldbetrag". Das Video nennt als Beispiele 10, 150 und 250 Euro (Folge 112, 46:01 und 61:30); das Modul kennt "als Datum nur noch einen Geldbetrag" und nichts über die Reparatur (45:49).

Ablageort

Eigenes Projekt in der Versionskontrolle, siehe ADR-011 (Folge 112, 54:13). Code gibt es nicht.

Offene Punkte

R-010 aus ADR-004: Läuft das System in der Cloud, muss Bezahlung die Kasse im Laden erreichen (Board Seite 10, "Kann man aus der Cloud in die Kasse kommunizieren?"). R-011: Der Zahlungsstatus kommt aus zwei Quellen.

Ebene 2

Note
 Offen: Das Board zeigt keine Ebene 2. Kein Baustein ist als Whitebox zerlegt, und ohne Code lässt sich keine innere Struktur ableiten. Die Serie endet mit Folge 113 auf Ebene 1.

Ebene 3

Note
 Offen: Nicht vorhanden, siehe Ebene 2.