© best_vector/Shutterstock.com
Windows Developer
Struktur für große Angular-Anwendungen

Ordnung im Unternehmen

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.

Manfred Steyer


Video: Web goes Native: Progressive Web App (PWA) - with Angular

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.

Abb. 1: Typische Modulstruktur

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.

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 ber...

Windows Developer
Struktur für große Angular-Anwendungen

Ordnung im Unternehmen

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.

Manfred Steyer


Video: Web goes Native: Progressive Web App (PWA) - with Angular

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.

Abb. 1: Typische Modulstruktur

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.

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 ber...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang