Manfred Steyer Selbstständig

Das Bordmittel zum Strukturieren von Angular-Anwendungen sind Angular-Module. Sie bieten dem Angular-Compiler nötige Kontextinformationen, indem sie zusammengehörige Building Blocks wie Komponenten oder Direktiven bündeln.

Angular wurde für große Unternehmensanwendungen entworfen. Allerdingst stellt sich schnell die Frage, wie man die damit entwickelten Anwendungen strukturiert, damit sie langfristig wartbar bleiben. Wie so oft ist die Antwort auf dieses Problem, dass man in kleinen Schritten vorgeht und kleine Pakete nutzt, um Großes zu erreichen. Die Kunst liegt darin, die Pakete richtig zu packen.

Nachdem ich in der letzten Ausgabe den Microservices-Ansatz vor dem Hintergrund von Angular beleuchtet habe, stelle ich hier ein paar zusätzliche Ideen vor, die sich in der Praxis bewährt haben. Dazu gehört der Einsatz von Angular-Modulen, aber auch das Schaffen von wiederverwendbaren npm-Paketen. Als Alternative zu npm-Paketen gehe ich auch auf den Monorepo-Ansatz ein. Ihn setzen beispielsweise Google und Facebook erfolgreich ein.

Angular-Module schneiden

Das Bordmittel zum Strukturieren von Angular-Anwendungen sind Angular-Module. Sie bieten dem Angular-Compiler nötige Kontextinformationen, indem sie zusammengehörige Building Blocks wie Komponenten oder Direktiven bündeln. Außerdem kann jedes Modul Services registrieren, die jedoch – auch wenn das verwundern mag – global zur Verfügung stehen. Wenn man mit einem neuen Angular startet, stellt sich sofort die Frage, wie die einzelnen Systembestandteile zu schneiden sind. Als Faustregel bietet sich die in Abbildung 1 gezeigte Modulstruktur an.

Die hier aufgezeigten Modularten helfen bei der gedanklichen Strukturierung. Angular selbst trifft keine Entscheidung, abgesehen davon, dass das Hauptmodul (hier Root Module) die Startkomponente bekannt gibt. Wie dieses Schema zeigt, erhält jedes Feature ein eigenes Featuremodul. Bei Geschäftsanwendungen stellt in erster Näherung jeder Use Case bzw. jede Userstory ein Feature dar. Ich habe es mir angewöhnt, zumindest mit dieser Kategorisierung zu starten und bei Bedarf das Modul in mehrere kleinere Module zu splitten. Dabei orientiere ich mich an der aus der Psychologie bekannten 7+/-2-Regel, die besagt, dass man ungefähr eben so viele Elemente im Überblick behalten kann. Übersteigt die Anzahl meiner Deklarationen diese Regel, führe ich neue Module für Subfeatures ein. Das ist häufig problemlos, weil sich die meisten Use Cases mehr oder weniger natürlich untergliedern lassen: Flug buchen setzt sich zum Beispiel aus Flug auswählen, Passagierdaten erfassen und Zahlungsdaten erfassen zusammen.

Abb. 1: Typische Modulstruktur

Abb. 1: Typische Modulstruktur

Neben den Featuremodulen zeigt das hier präsentierte Schema auch ein Shared Module. Davon kann es eines oder auch mehrere geben. Die Idee dahinter ist es, featureübergreifende Aspekte wie allgemeine Validierungslogiken, Authentifizierung oder Logging unterzubringen. Manche Entwickler sehen daneben auch noch ein Core Module vor, das die Shell der Anwendung sowie globale Services bereitstellt. Mit Shell sind die Hauptkomponente und jene Komponenten, die das Drumherum der Anwendung repräsentieren, gemeint, also z. B. Menüs oder Fußzeilen.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 4.18 - "Eine Frage der Architektur"

Alle Infos zum Heft
579830388Struktur für große Angular-Anwendungen
X
- Gib Deinen Standort ein -
- or -