Architektur

Angular — Architektur

0:00 Architektur ist das Thema, bei dem in Entwicklerrunden am meisten geredet und am wenigsten entschieden wird. Das liegt daran, dass die Frage meistens falsch gestellt wird. Sie lautet nicht: Welche Architektur ist die beste? Sondern: Welches Problem habe ich gerade, und was ist die kleinste Struktur, die es löst? In diesem Modul gehen wir drei Stufen durch, die alle innerhalb eines einzigen Angular-Projekts bleiben — vom bewusst schlichten Anfang über die Gliederung nach Fachbereichen bis zu einem Werkzeug, das Architekturregeln beim Bauen prüft.

0:31 Alles, was darüber hinausgeht, folgt im nächsten Modul.

Architekturmuster für Angular

0:35 Die Reihenfolge dieser drei Themen ist kein Zufall, sondern eine Leiter. Ganz unten steht die Haltung: Fang klein an. Darüber das Feature-Shell-Muster, das eine Anwendung nach Fachbereichen gliedert und selten genutzte Bereiche erst bei Bedarf lädt. Und darüber Sheriff, ein kleines Werkzeug, das dafür sorgt, dass diese Grenzen nicht heimlich wieder aufweichen. Jede Stufe löst einen konkreten Schmerz der vorigen.

0:58 Wenn Sie den Schmerz nicht benennen können, brauchen Sie die Stufe nicht — das ist der rote Faden durch dieses und das nächste Modul.

Emergente Architektur

1:07 Bevor wir über Muster reden, eine Folie über die Haltung dahinter. Ich halte sie für die wichtigste des Moduls, weil sie darüber entscheidet, ob alles Folgende nützt oder schadet. Es geht um die Frage, wann man Struktur einzieht — und die Antwort ist unbequemer, als man hofft. Sie klingt banal — fang klein an — und ist trotzdem die Stufe, an der die meisten Projekte scheitern.

1:30 Emergente Architektur heißt: Sie fangen mit der einfachsten Struktur an, die trägt, und erweitern sie erst, wenn Sie an einer konkreten Stelle Schmerz spüren. Das Gegenteil ist der große Entwurf am Anfang — jene Architektur, die für die Anwendung gedacht ist, die das Projekt in drei Jahren sein wird. Der Haken daran ist bekannt: Man weiß heute nicht, was in drei Jahren gebraucht wird. Was man am Anfang sicher weiß, ist nur, was jetzt fehlt.

1:56 Also baut man für jetzt und lässt die Struktur mitwachsen. Umbauen kann man immer. Der erste Punkt ist der, den Erfahrung lehrt: Große Vorabentwürfe treffen die späteren Anforderungen selten. Der zweite ist der, der wirklich weh tut. Wenn die Architektur nicht passt, wird nicht die Architektur geändert — sondern der Code hineingezwängt.

2:16 Man erkennt solche Projekte an Ordnern, in denen Dinge liegen, die dort nicht hingehören, und an Kommentaren, die erklären, warum das hier eine Ausnahme ist. Der dritte Punkt ist die Entwarnung: Refactoring bleibt möglich. Und der vierte ist der, den man beim Einarbeiten neuer Kolleginnen und Kollegen spürt. Lesen Sie diese Tabelle von rechts nach links. Die interessante Spalte ist nicht, wie eine Stufe heißt, sondern welchen Schmerz sie löst.

2:42 Feature-Shells lohnen sich, wenn der Erststart träge ist oder Zuständigkeiten verschwimmen. Sheriff lohnt sich, wenn Bereiche sich Abhängigkeiten einfangen, die niemand wollte. Das Monorepo lohnt sich bei Merge-Konflikten und auseinanderlaufenden Team-Prioritäten. Und Micro-Frontends lohnen sich, wenn Teams beim Ausliefern aufeinander warten müssen.

3:02 Wenn Sie den Schmerz in der rechten Spalte nicht wiedererkennen, ist die Stufe links davon für Sie kein Fortschritt, sondern Ballast. Der erste Punkt ist der Klassiker der letzten Jahre: Micro-Frontends aufsetzen, obwohl es genau ein Team gibt. Die Architektur ist dann nicht falsch, sie ist nur unbezahlt — man trägt die Komplexität, ohne den Nutzen zu haben.

3:23 Der zweite Punkt ist die Ursache dafür: nach Konferenzvortrag bauen statt nach eigener Beobachtung. Der dritte ist der soziale Druck, der einfache Lösungen als unambitioniert abtut. Und der vierte ist die Gegenrichtung, die ich genauso oft sehe: Man erträgt denselben Schmerz seit zwei Jahren und nennt das Pragmatismus.

Das Feature-Shell-Muster

3:43 Kommen wir zur ersten Stufe, die wirklich etwas verändert. Der Anlass ist meist banal und trotzdem berechtigt: Ein Bereich der Anwendung wird selten besucht, belastet aber trotzdem jeden einzelnen Seitenaufruf. Das lässt sich mit überschaubarem Aufwand ändern. Ein Fachbereich, den kaum jemand aufruft, kostet trotzdem jeden Erstbesucher Ladezeit.

4:03 Das ist ein guter Anlass für die erste Strukturstufe — und einer, den man sogar messen kann. Das Muster ist einfacher, als der Name vermuten lässt: Sie gliedern die Anwendung nach Fachbereichen, geben jedem Bereich eine eigene Routendatei und laden ihn erst, wenn er gebraucht wird. Bei unserem Fahrradteile-Shop heißt das: Der Laden selbst ist das eine, die Kontoverwaltung das andere.

4:26 Wer nur Bremsbeläge anschauen will, muss den Code für Bestellhistorie und Adressverwaltung gar nicht erst herunterladen. Man kann sich das vorstellen wie ein Kaufhaus, das die oberen Stockwerke erst beleuchtet, wenn jemand die Rolltreppe betritt. Der erste Punkt ist messbar und deshalb ein gutes Argument im Team: Der Erststart lädt weniger.

4:45 Bei einem Shop, dessen Sichtbarkeit in Suchmaschinen an der Ladezeit hängt, ist das kein Feinschliff, sondern Geschäft. Die anderen drei Punkte sind weicher und auf lange Sicht mindestens genauso wertvoll. Wenn Fachbereiche im Dateibaum sichtbar sind, kann man Zuständigkeiten daran festmachen — und die Frage „wer kümmert sich darum" hat plötzlich eine Antwort, auf die man zeigen kann.

5:07 Struktur im Code wird so zu Struktur im Team. Die ersten beiden Schritte sind Umzugsarbeit: Ordner anlegen, alles Zusammengehörige hineinziehen. Der dritte Schritt ist der, der aus einem Ordner einen Fachbereich macht — die eigene Routendatei. Ohne die haben Sie nur aufgeräumt. Der vierte hängt den Bereich als Elternroute in die Anwendung, und zwar mit einem verzögerten Import.

5:31 Und der fünfte ist der, den man beim ersten Mal vergisst: Alles, was auf die alten Pfade zeigt, muss mit. Navigation, Weiterleitungen, Links im Kopfbereich. Nichts davon ist schwierig, aber es ist mehr, als man denkt. Worauf es hier ankommt, ist der Unterschied zwischen den beiden Einträgen. Beim Shop stehen die Kindrouten direkt da — der Bereich wird sofort mitgeladen.

5:53 Beim Konto steht stattdessen eine Funktion, die den Import erst ausführt, wenn jemand dorthin navigiert. Das ist der ganze Trick. Und beachten Sie, dass hier bewusst nicht alles verzögert geladen wird. Den Hauptbereich, den ohnehin jeder zuerst sieht, verzögert zu laden, macht die Sache langsamer statt schneller — man verschiebt die Arbeit nur um einen Wimpernschlag nach hinten.

6:16 Diese Aufgabe hat ein schönes Erfolgskriterium, weil es objektiv nachprüfbar ist: Öffnen Sie den Netzwerk-Tab und navigieren Sie in den neuen Bereich. Wenn dabei ein zusätzliches Paket nachgeladen wird, hat es funktioniert. Wenn nicht, war der Bereich schon vorher dabei. Die Kür lohnt sich besonders: Schauen Sie nach, um wie viel das Startpaket kleiner geworden ist.

6:37 Diese Zahl ist das Argument, mit dem Sie im Team begründen, warum sich der Umbau gelohnt hat — und sie fällt oft deutlicher aus, als man erwartet. Der erste Punkt ist der, der beim ersten Versuch garantiert passiert: Nach dem Verschieben zeigen Pfade ins Leere. Das betrifft Konfigurationsdateien genauso wie die Navigation.

6:56 Der zweite Punkt ist der begriffliche: Ein Ordner allein ist noch kein Feature-Shell. Ohne eigene Routen haben Sie umsortiert, nicht entkoppelt. Der dritte ist die Übertreibung, die wir eben besprochen haben. Und der vierte ist der, den die Nutzer als Erstes merken: Die Weiterleitung auf der Startseite zeigt noch auf den alten Pfad, und die Anwendung startet mit einer leeren Seite.

Grenzen durchsetzen mit Sheriff

7:19 Sie haben jetzt Fachbereiche. Die Frage ist, wie lange sie Fachbereiche bleiben. Denn Grenzen im Dateisystem sind Absprachen, und Absprachen weichen auf — meist nicht aus Böswilligkeit, sondern weil ein Import gerade praktisch war. Genau dafür gibt es ein erstaunlich kleines Werkzeug. Der Import über die Bereichsgrenze ist ja nie böswillig: Er ist praktisch, er passt gerade, und er steht drin, bevor jemand darüber nachgedacht hat.

7:45 Sheriff prüft, wer von wem importieren darf. Sie versehen Ordner mit Etiketten — etwa „Domäne Shop" und „Domäne Konto" — und legen anschließend fest, aus welchen Domänen jede importieren darf. Der Vergleich, der mir dazu einfällt, ist ein Gebäude mit Zutrittskarten: Nicht jede Tür steht jedem offen, und wer es trotzdem versucht, merkt es sofort und nicht erst bei der Inventur.

8:08 Wichtig ist das Wort „Bauzeit". Sheriff läuft, während Sie bauen, nicht während die Anwendung läuft — der Verstoß fällt also auf, bevor er irgendwo ankommt. Der erste Punkt beschreibt, wie Kopplung tatsächlich entsteht: nie durch eine Entscheidung, immer durch viele kleine Bequemlichkeiten. Niemand beschließt, zwei Bereiche zu verheiraten — jemand importiert nur eine Hilfsfunktion, weil sie zufällig passt.

8:32 Der zweite Punkt ist der Zeitpunkt: Sie merken es beim Bauen und nicht erst, wenn Sie einen Bereich herauslösen wollen und feststellen, dass er festgewachsen ist. Und der vierte Punkt ist der, den ich unterschätzt hatte: Die Konfigurationsdatei ist zugleich die beste Dokumentation der beabsichtigten Architektur, die Sie haben können — sie ist nämlich zwangsläufig aktuell.

8:54 Fünf Schritte, von denen vier in zehn Minuten erledigt sind. Installieren, die Konfiguration erzeugen lassen, Etiketten vergeben, Regeln schreiben, ein Skript anlegen. Der letzte Schritt ist der, der über Erfolg oder Wirkungslosigkeit entscheidet: das Skript in die Bau-Pipeline hängen. Eine Prüfung, die nur läuft, wenn jemand daran denkt, ist keine Prüfung, sondern eine Erinnerung. Und Erinnerungen verlieren im Alltag zuverlässig gegen Termindruck.

9:20 Erst wenn ein Verstoß den Build rot macht, wirkt die Regel. Der Aufbau ist zweiteilig: Oben stehen die Etiketten, unten die Regeln. Und die Regeln sind eine Erlaubnisliste, keine Verbotsliste — was nicht dasteht, ist untersagt. Das ist die richtige Voreinstellung, weil neue Kopplung dann automatisch auffällt, statt automatisch durchzurutschen.

9:41 Ein Detail, das beim ersten Mal jeden erwischt, steht in der Fußzeile: Die oberen Ebenen brauchen ebenfalls ein Etikett. Sonst meldet Sheriff einen Verstoß in Ihrer Hauptroutendatei — die ja per Definition alle Bereiche kennen muss. Das ist kein Fehler des Werkzeugs, aber es kostet beim Einrichten fünf verwirrte Minuten.

10:01 Diese Aufgabe dreht die übliche Richtung um: Sie sollen etwas kaputt machen. Bauen Sie absichtlich einen Import über eine Bereichsgrenze und schauen Sie, ob Sheriff anschlägt. Geschafft haben Sie es, wenn das Werkzeug den Verstoß meldet und nach der Korrektur wieder schweigt. Warum dieser Umweg? Weil eine Prüfung, die man nie hat auslösen sehen, kein Vertrauen verdient. Ein grünes Ergebnis kann auch bedeuten, dass die Konfiguration gar nicht greift.

10:28 Diese fünf Minuten sind gut investiert. Den ersten Punkt haben wir gerade besprochen — er kostet jeden einmal Nerven. Der zweite ist der, der die ganze Übung wertlos macht: Sheriff nur lokal laufen zu lassen. Der dritte ist der schleichende und deshalb gefährlichste: Bei jeder Meldung die Regel aufzuweichen. Dann wandert die Erlaubnisliste Zeile für Zeile in Richtung „alles erlaubt", und am Ende haben Sie eine Konfigurationsdatei, die nichts mehr prüft, aber ordentlich aussieht.

10:57 Fragen Sie bei jeder Meldung zuerst, ob der Import berechtigt ist — und nicht, wie Sie ihn erlauben. Und schneiden Sie die Etiketten nicht zu fein. Der wichtigste Satz dieses Moduls steht ganz oben und gilt auch fürs nächste: Jede Stufe muss durch einen benennbaren Schmerz bezahlt sein. Feature-Shells gliedern nach Fachbereichen und laden sie bei Bedarf — das kostet wenig und bringt sowohl Ladezeit als auch Klarheit über Zuständigkeiten.

11:22 Sheriff macht aus einer Absprache eine Prüfung, und zwar zur Bauzeit. Und der vierte Punkt ist der, den man im Kopf behalten sollte: Alles, was wir heute gesehen haben, bleibt innerhalb eines einzigen Angular-Projekts. Für viele Teams ist genau hier der richtige Endpunkt.

Fragen & Weiterarbeiten

11:38 Im nächsten Modul geht es über die Projektgrenze hinaus. Dort wird aus einem Projekt ein Monorepo mit mehreren Anwendungen, und aus dem Monorepo werden Micro-Frontends mit getrennten Repositories. Die Fragen ändern sich dabei grundlegend: Es geht nicht mehr um Code, der sich sauber trennen lässt, sondern um Teams, die einander beim Ausliefern nicht im Weg stehen sollen.

11:58 Wenn Sie sich in Sheriff einlesen möchten — die Dokumentation zu Etiketten und Regeln ist knapp und in einer halben Stunde durchgearbeitet. Fragen dazu gerne jetzt.