Feature-Architektur und Zuständigkeiten

Feature-Architektur und Zuständigkeiten

0:00 Ich sage Ihnen etwas, das nach einer steilen These klingt und trotzdem meiner Erfahrung entspricht: Die meisten Angular-Projekte scheitern nicht an Angular. Sie scheitern an Komponenten, die zu viel wissen. Keine davon war von Anfang an so — sie sind gewachsen, Zeile für Zeile, und jede einzelne Erweiterung war nachvollziehbar.

0:19 In diesem Modul geht es darum, wie man das verhindert: mit drei klaren Rollen, mit Zustand am richtigen Ort und mit Entscheidungen, die man aufschreibt.

Reaktivität und Anwendungsstruktur

0:28 Das ist das letzte Modul des zweiten Tages. Gestern die Bausteine, heute der Zustand und die Verdrahtung — und jetzt die Frage, wie das alles zusammen einen Zuschnitt ergibt, der auch im dritten Jahr noch trägt.

Zuständigkeiten sauber schneiden

0:40 Beginnen wir mit der Aufteilung selbst. Drei Rollen, drei Orte — und der häufigste Fehler besteht darin, dass alle drei in derselben Datei wohnen. Der Style Guide ist hier eindeutig: Komponenten beschränken sich auf die Darstellung, komplexe Logik wird ausgelagert. Daraus ergeben sich drei Rollen. Die Komponente zeigt an und meldet Absichten. Der Service entscheidet fachlich. Der Datenzugriff holt und schreibt.

1:06 Denken Sie an ein Restaurant — wir hatten das Bild schon: Der Kellner nimmt auf und serviert, die Küche entscheidet, wie gekocht wird, der Einkauf besorgt. Wenn der Kellner kocht, funktioniert das eine Weile. Bis mehr als drei Gäste da sind. Diese Schichtung sieht selbstverständlich aus und ist es im Alltag selten. Lesen Sie sie von oben: Die Komponente kennt den Feature-Service.

1:29 Der Feature-Service kennt den Datenzugriff. Der Datenzugriff kennt die Schnittstelle. Und jetzt der entscheidende Punkt — die Pfeile gehen nur nach unten. Die Komponente kennt die Schnittstelle nicht, und sie kennt vor allem deren Feldnamen nicht. Sobald in einem Template ein Feldname auftaucht, der aus der Schnittstelle stammt, ist eine Schicht übersprungen worden.

1:50 Das ist ein gutes Suchkriterium für einen Rundgang durch fremden Code. Vier Anzeichen, und ich finde das zweite am aussagekräftigsten: Ihr Test braucht eine gerenderte Ansicht, um eine Regel zu prüfen. Das ist der Moment, in dem man merkt, dass eine fachliche Entscheidung am falschen Ort liegt — denn eine Regel hat mit Darstellung nichts zu tun.

2:11 Das erste Anzeichen ist das eben genannte mit den Feldnamen. Das dritte: Eine fachliche Änderung erzwingt eine Änderung am Template. Und das vierte ist eher ein Geruch als ein Beweis: mehr private Methoden als Bindungen. Der erste Punkt beschreibt den Entstehungsweg: Die Fachregel steht im Template, weil sie dort zuerst gebraucht wurde.

2:31 Niemand hat entschieden, dass sie dorthin gehört — sie war dort am schnellsten geschrieben. Der zweite ist die Gegenrichtung und genauso ungünstig: Der Service reicht Daten nur durch und trägt keine Entscheidung. Dann haben Sie eine Schicht, die nichts tut, außer Zeilen zu kosten. Und der dritte ist die Spätfolge von beidem: Zwei Komponenten enthalten dieselbe Regel in leicht abweichender Fassung — und eine davon ist falsch.

Features ohne globale Zustandsverwaltung

2:56 Kommen wir zu einer Entscheidung, die in vielen Projekten viel zu früh getroffen wird — und die man erstaunlich gut hinauszögern kann. Zustand gehört dorthin, wo er gebraucht wird. Ein Feature-Service, der an der Route bereitgestellt wird, lebt genau so lange wie das Feature — das haben wir im letzten Modul vorbereitet. Eine anwendungsweite Zustandsverwaltung ist dagegen eine Produktentscheidung mit Folgekosten: ein zusätzliches Konzept, das jeder im Team lernen muss, und eine zusätzliche Abhängigkeit, die versioniert werden will.

3:27 Sie lohnt sich, wenn mehrere Features denselben Zustand wirklich teilen. Das Wort „wirklich" trägt den Satz. Die interessanteste Zeile ist die dritte: löschbar mit dem Feature gegen wächst dauerhaft. Ein Feature-Store verschwindet, wenn das Feature verschwindet — automatisch, ohne dass jemand aufräumen muss. Ein globaler Store wächst, weil niemand sich traut, etwas daraus zu entfernen; man weiß ja nie, wer es liest.

3:52 Die letzte Zeile ist die ehrliche: Der eine braucht kein Zusatzwerkzeug, der andere ist eine Produktentscheidung. Beides ist legitim. Nur sollte man wissen, welche der beiden man gerade trifft. Vier Fragen, und der Trick daran ist, dass man sie in dieser Reihenfolge stellt. Zuerst: Welche zwei Features lesen denselben Zustand?

4:13 Wenn Sie hier ins Stocken geraten, ist die Frage schon beantwortet. Dann: Kann ein gemeinsamer Vorfahre ihn halten? Dann: Decken Signals im Service den Bedarf bereits ab? Und erst danach: Welches Produkt? Die Fußzeile ist mir wichtig — eine früh eingeführte Zustandsverwaltung kostet dauerhaft, auch wenn der geteilte Zustand, für den sie gedacht war, nie entsteht.

4:37 Der erste Punkt ist der ehrlichste von allen: Ein globaler Store entsteht aus Gewohnheit, nicht aus Bedarf — weil man das im letzten Projekt so gemacht hat. Der zweite ist der Sog, der danach einsetzt: Lokaler Zustand wandert in den Store, damit alles an einer Stelle liegt. Das klingt ordentlich und macht jedes Feature von allen anderen abhängig. Und der dritte ist die Altlast: Zustand bleibt im Store, obwohl das Feature längst entfernt wurde.

5:02 Niemand traut sich, ihn zu löschen.

Fehlerbehandlung als Entwurfsfrage

5:05 Jetzt zu einem Thema, das selten als Architekturfrage behandelt wird und genau das ist: Was passiert, wenn etwas nicht klappt? Ein erwarteter Fachfehler — der Auftrag ist gesperrt, der Standort unbekannt — ist Teil Ihres Modells. Er gehört in den normalen Ablauf, nicht in eine Ausnahmebehandlung. Eine technische Störung ist etwas völlig anderes und braucht eine eigene Behandlung.

5:28 Und dann gibt es noch eine dritte Unterscheidung, die oft fehlt: Wo eine Meldung entsteht und wo sie angezeigt wird, sind zwei verschiedene Entscheidungen. Der Datenzugriff weiß, dass etwas schiefging. Er weiß nicht, wie der Benutzer das erfahren soll. Drei Zeilen, drei völlig verschiedene Reaktionen — das ist der Inhalt dieser Tabelle.

5:48 Ein Fachfehler gehört ins Modell und wird am verursachenden Feld angezeigt; er ist Teil des Ablaufs, kein Zwischenfall. Eine technische Störung wird zentral behandelt, gegebenenfalls mit Wiederholung, und der Benutzer bekommt eine Meldung, die ihm etwas sagt. Und die dritte Zeile ist die, die man gern vergisst: Ein Programmfehler — der Zugriff auf eine leere Auswahl — gehört gar nicht in die Fehlerbehandlung.

6:12 Er gehört in einen Test, der ihn verhindert. Der erste Punkt ist die Sammelbox-Lösung: Jeder Fehler wird gleich behandelt und landet in derselben Meldung oben rechts. Für den Benutzer sieht dann ein Tippfehler aus wie ein Serverausfall. Der zweite ist ein Schichtverstoß: Die Meldung entsteht tief im Datenzugriff und trägt technische Details nach außen — Tabellennamen, Pfade, Statuscodes.

6:35 Und der dritte ist der gefährlichste, weil man ihn nicht sieht: Ein fehlgeschlagener Aufruf wird stumm verworfen. Der Benutzer denkt, es hat geklappt.

Architekturentscheidungen festhalten

6:44 Zum Abschluss etwas, das keine fünf Minuten kostet und über Jahre wirkt. Es geht ums Aufschreiben — und zwar nicht des Wie, sondern des Warum. Ein Architekturentscheid hält vier Dinge fest: den Kontext, die betrachteten Optionen, die Wahl und ihre Begründung. Kurz, datiert, neben dem Code versioniert. Und er nennt noch etwas Fünftes, das fast immer fehlt: was die Entscheidung wieder öffnen würde.

7:09 Ohne dieses Dokument wird dieselbe Frage jedes Jahr neu diskutiert — aber ohne die Gründe von damals. Man weiß dann nur noch, dass man sich anders entschieden hat, nicht warum. Und dann entscheidet man beim nächsten Mal nach Tagesform. Fünf Schritte, und drei davon sind Disziplin. Der Anlass in drei Sätzen, ohne die Lösung vorwegzunehmen — das ist schwerer, als es klingt, weil man die Lösung ja schon im Kopf hat.

7:35 Zwei bis drei ernsthaft geprüfte Optionen, Betonung auf ernsthaft: eine Alternative, die man nur aufschreibt, um sie zu verwerfen, ist keine. Die Wahl mit den Gründen, die den Ausschlag gaben. Dann das, was sie wieder aufmachen würde. Und datieren — sonst weiß in zwei Jahren niemand, ob das Dokument aktuell ist. Der erste Punkt ist der häufigste und macht das Dokument fast wertlos: Nur die gewählte Option steht darin.

8:01 Dann ist es eine Beschreibung, keine Begründung — und beim nächsten Mal weiß niemand, ob die Alternative geprüft wurde. Der zweite: Der Entscheid beschreibt die Umsetzung statt der Begründung. Die Umsetzung steht im Code und ändert sich; die Begründung nicht. Und der dritte ist organisatorisch: Er liegt im Wiki und veraltet, weil ihn niemand mit dem Code ändert. Neben den Code damit.

Übung

8:25 Machen wir das Praktische daraus. Wir entflechten eine Komponente, die genau so gewachsen ist, wie ich es beschrieben habe. Die Auftragskomponente in Spurweite hat alles eingesammelt: Sie lädt Daten, filtert, prüft, ob ein Auftrag noch bearbeitet werden darf, formatiert Meldungen und zeigt an. Der Auslöser für diese Übung war eine kleine Änderung — die Prüfregel sollte um einen Fall erweitert werden. Und dafür musste jemand das Template anfassen.

8:52 Das ist der Moment, an dem man merkt, dass etwas nicht stimmt: wenn eine fachliche Änderung eine Darstellungsdatei berührt. Das Lernziel nennt die Probe, an der sich alles entscheidet: Die Regel soll ohne gerenderte Ansicht prüfbar werden. Das Erfolgskriterium hat drei Teile — die Regel liegt im Feature-Service, ein Test kommt ohne Rendering aus, und die Komponente kennt keine Feldnamen der Schnittstelle mehr.

9:16 Achten Sie auf den letzten: Er ist der objektivste von allen, weil man ihn durch Nachsehen prüfen kann. Wer früh fertig ist, ergänzt die Fehlerbehandlung für den Fall, dass ein Auftrag gesperrt ist — und ordnet ihn dabei in die richtige der drei Zeilen ein. Der zweite Schritt ist der, der die Arbeit macht: Je Zeile eine Rolle zuordnen — anzeigen, entscheiden, holen.

9:38 Das ist mühsam und es lohnt sich, weil danach offensichtlich ist, was verschoben werden muss. Der vierte Schritt ist die Probe: ein Test, der die Regel ohne Rendering prüft. Wenn der grün wird, war die Trennung erfolgreich. Und der fünfte ist der, den man am liebsten weglässt: eine Seite Architekturentscheid. Fünfzehn Minuten, und in einem Jahr fragt jemand genau danach.

10:01 Der erste Punkt ist der halbe Umbau, und er ist schlimmer als gar keiner: Der Service entsteht, die Regel bleibt zusätzlich im Template stehen. Jetzt existiert sie zweimal, und eine der beiden wird irgendwann nicht mitgepflegt. Der zweite ist ein Versehen mit Folgen: Der Zustand wandert anwendungsweit statt an die Route.

10:20 Und der dritte ist der, vor dem ich eben gewarnt habe: Der Entscheid nennt die Lösung, aber nicht die verworfenen Optionen. Damit endet der zweite Tag. Morgen geht es um Navigation, Daten und Formulare — den sichtbaren Teil.