Aufgabe 18 - Schichtwechsel

Aufgabe 18 - Schichtwechsel

Worum geht es?

Sie bringen Architektur in Ihr Buffet-Projekt: drei sauber getrennte Schichten und den praktischen Beweis, dass die Trennung trägt, indem die Datenschicht ausgetauscht wird, ohne dass die anderen es merken (siehe Kapitel Mehrschichtarchitektur). Der Umbau läuft als eigener Branch mit Merge Request; er ist zugleich die Generalprobe für den Team-Workflow.

Was Sie dafür brauchen

• Kapitel Mehrschichtarchitektur; Ihr Buffet-Projekt aus den Aufgaben 15 und 16; der geschulte Blick aus Aufgabe 17.

Welche Kompetenzen Sie erwerben und zeigen

• Sie strukturieren ein bestehendes Projekt in Präsentation, Services und Repositories um.
• Sie setzen die Abhängigkeitsregeln durch (Handler ohne Geschäftslogik, Services ohne HTTP).
• Sie weisen Austauschbarkeit nach: Implementierungswechsel an genau einer Stelle.

Pädagogische Einordnung

• Reproduktion: die Zielstruktur des Kapitels auf das eigene Projekt übertragen (Teil A).
• Reorganisation und Transfer: bestehenden Code verhaltensneutral umbauen (Teil B).
• Reflexion, Problemlösung und Urteilsbildung: den Architekturnutzen nachweisen und Kosten und Nutzen ehrlich abwägen (Teile C und D).

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt. Teil D ist der Expertenteil.

Teil A - Ist-Analyse

1. Zeichnen Sie das Ist-Diagramm Ihres Projekts: Welche Datei gehört (der Absicht nach) zu welcher Schicht, und wo verletzen Importe oder verirrte Logik die Regeln? Nutzen Sie die Suchmuster aus Aufgabe 17.
2. Markieren Sie mindestens drei Stellen, die umziehen müssen (typisch: Mengenprüfung im Handler, Statusübergangsregeln verstreut, Datenzugriff direkt in der Seite).

Teil B - Der Umbau

1. Zielstruktur herstellen: app/ (Seiten und Route Handler als dünne Adapter), lib/services/buffet-service.ts (alle Geschäftsregeln: Positionsgrenzen, Mengen, Bestellschluss, Statusübergänge), lib/repository/ mit BuffetRepository-Interface und der bisherigen Speicherei als MemoryRepository.
2. Die zwei harten Regeln: Route Handler enthalten keine Geschäftsregel mehr (nur parsen, Service rufen, Antwort formen); Services kennen kein HTTP (keine Statuscodes, keine Request/NextResponse-Importe). Fachliche Fehler wirft der Service als eigene Exception-Klassen; die Übersetzung in Statuscodes wohnt am Rand.
3. Der Umbau läuft auf einem Branch refactor/layers; committen Sie in nachvollziehbaren Schritten (Service extrahiert, Repository extrahiert, Handler verdünnt).

Teil C - Der Beweis

1. Ihr Abnahmeskript aus Aufgabe 15 muss nach dem Umbau unverändert bestehen: Es testet den Vertrag, nicht die Struktur; genau dafür war es da. Ein gebrochener Abnahmefall bedeutet: Der Umbau war nicht verhaltensneutral; beheben.
2. Schreiben Sie die zweite Repository-Implementierung JsonFileRepository (Bestand überlebt den Neustart) gegen dasselbe Interface.
3. Der Wechsel zwischen Memory und Datei betrifft genau eine Stelle (die Verdrahtung der Instanzen). Halten Sie den Diff dieses Wechsels fest; er ist Ihr Architektur-Zeugnis.

Teil D - Expertenteil: Merge Request und Abwägung

1. Stellen Sie den Umbau als Merge Request mit ordentlicher Beschreibung (was, warum, wie geprüft) und lassen Sie ihn von einer Kollegin oder einem Kollegen anhand der Importregeln reviewen; mindestens zwei Anmerkungen müssen beantwortet werden, dann Merge.
2. Härtetest der Trennung: Implementieren Sie eine neue Geschäftsregel (“höchstens eine offene Bestellung pro Person”) und protokollieren Sie, welche Dateien Sie anfassen mussten. Soll: Service und Test, sonst nichts.
3. Schreiben Sie die Reflexion (vier bis sechs Sätze): Was hat der Umbau gekostet? Was ist mit der neuen Regel aus Punkt 2 leichter geworden? An welcher Stelle fühlt sich die Struktur für die Projektgröße nach Overkill an, und warum ist sie fürs Abschlussprojekt trotzdem verbindlich?
4. Zusatz: Formulieren Sie die Importregeln Ihres Projekts als kurze Team-Konvention in der README (drei Zeilen), reviewfähig für Aufgabe 21.

Wissenscheck

1. Was darf ein Route Handler nach dem Umbau noch, und was ausdrücklich nicht mehr?
2. Warum wirft der Service fachliche Exceptions statt Statuscodes zurückzugeben?
3. Was beweist der unveränderte Durchlauf des Abnahmeskripts?
4. Warum darf der Repository-Wechsel nur eine Stelle betreffen, und wie heißt das Muster, das das ermöglicht?
5. Welche drei Faktoren kippen die Abwägung zugunsten der Schichten?

Abgabe

Git-Repository mit gemergtem refactor/layers-MR (Review-Verlauf zählt), Schichten-Diagramm vorher/nachher, Wechsel-Diff, Protokoll der neuen Regel und die Reflexion.