--- type: "post" title: "Angular at Scale – Best Practices für Enterprise-Applikationen" slug: null category: null tags: [] publishedOn: null --- # Angular at Scale – Best Practices für Enterprise-Applikationen **Große Angular-Projekte wachsen schnell – und mit ihnen die Komplexität. Wir zeigen, wie ein durchdachtes Setup Skalierbarkeit, Wartbarkeit und einen reibungslosen Teamwechsel über Jahre hinweg sicherstellt.** ## Anforderungen Seit mehreren Jahren liegt unser Fokus bei FORTIX auf der Entwicklung von **Enterprise-Applikationen mit Angular**. Dabei stehen vor allem drei Ziele im Vordergrund: Die Anwendungen sollen über ihre gesamte Lebensdauer hinweg **skalierbar** bleiben, sich **einfach warten** und erweitern lassen und gleichzeitig einen **leichten Einstieg** für neue Teammitglieder ermöglichen – unabhängig davon, wie groß oder wie wechselhaft ein Team aufgestellt ist. Gerade in großen Projekten verändern sich Teams im Laufe der Zeit. Rollen verändern sich, neue Mitarbeiter kommen hinzu und Anforderungen wachsen. Deshalb ist es wichtig, bereits zu Beginn des Projekts die nötige **Flexibilität im Setup** zu berücksichtigen. Eine gut strukturierte und wartungsfreundliche Architektur zahlt sich langfristig aus. Es gibt kaum etwas Ärgerlicheres als technische Altlasten, die zukünftige Weiterentwicklungen erschweren oder blockieren. ## Das Setup Unser bevorzugtes Setup basiert auf einem **NX Monorepo**, das mehrere Vorteile vereint. Es ermöglicht eine klare Trennung zwischen Anwendungen und Bibliotheken, sorgt für einheitliche und wiederverwendbare Standardbefehle und bietet effizientes Caching sowie schnelle Build-Prozesse. Durch diese Struktur lassen sich neue Anwendungen und Komponenten konsistent integrieren, was Wartung und Erweiterungen deutlich vereinfacht. ### Typische Struktur - **Component Library** – zentrale UI-Komponenten - **Style Library** – Themes, Layout, Variablen - **Utils Library** – generische Funktionen & Helfer - **Signal Stores** – schlankes State-Management - **NSwag-Generierung** – gemeinsame API-Typdefinitionen für Client & Server ### Warum NX Monorepo? Mit NX erreichen wir bereits die wesentlichen Projektanforderungen: - **Trennung zwischen Apps und Libraries** - Einfachere Wartung & Fehlersuche - **Wiederverwendbare Komponenten** - Schneller Aufbau neuer Anwendungen - **Team-freundliche Struktur** - Leichter Einstieg für neue Teammitglieder Neue Anwendungen können innerhalb des Monorepos **mit denselben UI-Komponenten und Tools** erstellt werden. Das steigert Konsistenz und reduziert Aufwand. ### Component Library Für die Component Library setzen wir häufig auf **DevExtreme** als Basis. Diese liefert eine große Auswahl an vorgefertigten UI-Komponenten wie Tabellen, Data Grids und Formularelementen. Wir erstellen **eigene Wrapper-Komponenten**, um Controls gezielt zuzuschneiden. Das spart Zeit und sorgt für **ein durchgängiges UI-Verhalten** im gesamten System. ### Warum Signal Store? Mit den **Angular Signal Stores** steht ein schlankes und sehr intuitives State-Management zur Verfügung. **Vorteile:** - Stores werden **feature-spezifisch** aufgebaut - sehr **übersichtliche Syntax** - weniger Boilerplate als NgRx - Migration von NgRx **schrittweise möglich** Der Store befindet sich **nah an der Komponente** → das verbessert Lesbarkeit und Testbarkeit. ### Instruction Files Damit Vorschläge von **GitHub Copilot** oder anderen AI-Tools den Projektstandards entsprechen, verwenden wir ein **instructions.md** im Repository. - Projektbeschreibung & Struktur - Coding-Guidelines - Namenskonventionen - Beispielcode So wird AI-generierter Code **direkt in der gewünschten Form** erzeugt. ## Testing & Wartung Für langfristig stabile Anwendungen setzen wir auf: - **Unit Tests** für Kernlogik & Helper - **E2E Tests** für kritische Userflows - **Regelmäßige Angular Updates**, um Tech Debt gering zu halten Eine klare Architektur erleichtert Testbarkeit automatisch. ## Wesentliche Punkte (Zusammenfassung) - **UI** - Basiskomponenten aus Library (DevExtreme + Wrapper) - **Zustand** - **Signal Stores**, nach Features getrennt - **Architektur** - Standalone Components + Library-Aufteilung - **AI-Unterstützung** - *instructions.md* zur Regelung von Copilot-Vorschlägen ## Ausblick: Micro Frontends Für sehr große Systeme oder mehrere unabhängige Teams kann der Einsatz von **Micro Frontends** sinnvoll sein. Dabei werden mehrere Frontend-Anwendungen separat entwickelt und deployt, aber in eine gemeinsame Shell eingebettet. So können Teams unabhängig arbeiten, Features releasen und gleichzeitig die Anwendungen als ein zusammenhängendes System präsentieren. Mit **Webpack Module Federation** lassen sich diese Micro Frontends zur Laufzeit laden und dynamisch kombinieren. Dies ermöglicht nicht nur unabhängige Deployments, sondern erlaubt auch den Einsatz unterschiedlicher Technologien innerhalb desselben Projekts und schafft klare Verantwortlichkeiten pro Team. Typische Anwendungsbeispiele sind Webshops, bei denen Checkout, Artikelverwaltung und Userverwaltung als separate Frontends implementiert werden, oder Plattformen wie Netflix, bei denen Startseite, Suche, Player und Profile voneinander entkoppelt sind und unabhängig weiterentwickelt werden können. ## Links - [Angular instruction example](https://angular.dev/ai/develop-with-ai/) - [Nx Monorepo](https://nx.dev/) - [DevExtreme Angular Components](https://js.devexpress.com/Overview/Angular/) - [Angular Signal Stores](https://angular.dev/guide/signals) - [Micro Frontends with Angular](https://www.angulararchitects.io/blog/micro-frontends-with-modern-angular-part-1-standalone-and-esbuild/)