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

![](/images/blog/angular-at-scale/component-library-schema.jpg 'Schema der Struktur mit Component Library')

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

![](/images/blog/angular-at-scale/signal-store.png 'Auszug Migration von NgRx zu Signal Stores')

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

![](/images/blog/angular-at-scale/instructions.jpg 'Beispiel eines instruction.md Files für AI-Unterstützung')

#### 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/)


Angular at Scale – Best Practices für Enterprise-Applikationen


Angular gehört seit Jahren zu den führenden Frameworks für skalierbare Webanwendungen – besonders im Enterprise-Umfeld. Die neue Version 20 setzt den Fokus nicht auf große Umbrüche, sondern auf Stabilität, moderne Standards und eine verbesserte Developer Experience.

Wir bei **FORTIX** haben uns die Neuerungen angesehen – hier unser Überblick und unsere Einschätzung.

### Was bringt Angular 20?

#### Zoneless Angular – ein großer Schritt näher

Mit Angular 20 ist zoneless change detection offiziell im Developer Preview angekommen. Die neue API `provideZonelessChangeDetection` ersetzt die bisher experimentelle Version – und zeigt: Angular macht ernst.  
Google nutzt Zoneless Angular bereits produktiv (z. B. bei Google Fonts), und erste Projekte berichten von spürbar besseren Lighthouse Scores.  
Auch in der Angular CLI ist das Thema angekommen: Beim Erstellen neuer Projekte (`ng new`) wird direkt gefragt, ob man eine zonenfreie App starten möchte.

#### Server-Side Rendering – stabiler und flexibler

Angular 20 bringt deutliche Verbesserungen im Bereich Server-Side Rendering (SSR). Zwei zentrale Features – **inkrementelle Hydration** und **Rendering-Konfiguration pro Route** – sind jetzt offiziell stabil.

Was bedeutet das in der Praxis?

- Komponenten können nachgeladen und hydratisiert werden, **wenn sie wirklich gebraucht werden**
- Entwickler:innen können flexibel steuern, **welche Seiten serverseitig, clientseitig oder vorgerendert** ausgeliefert werden

Das spart Ressourcen, verbessert die Ladezeiten und macht Angular-Anwendungen effizienter – besonders bei großen, dynamischen Webapps.

#### Developer Experience: smarter & klarer

Angular 20 bringt viele kleine, aber wirkungsvolle Verbesserungen für den Entwicklungsalltag – quer durchs gesamte Framework: Routing, Forms, HTTP, API-Design.  
Ein echtes Highlight: **Die neue Integration mit den Chrome DevTools**.  
Angular-spezifische Infos wie **Change Detection-Zyklen**, **Komponenten-Rendering** oder **Event-Handling** sind jetzt direkt im Performance-Panel sichtbar – farblich markiert und im Kontext anderer Prozesse im Browser.  
Das macht die Analyse komplexer Apps deutlich einfacher und präziser.

### Unsere Einschätzung

Angular 20 ist kein lauter Hype-Release – und genau das gefällt uns.  
Die Richtung stimmt: Angular entwickelt sich mit Bedacht weiter, bleibt dabei aber **stabil, modern und zukunftssicher**.  
Besonders spannend: die Fortschritte bei **SSR** und **Signals** – Themen, die in vielen unserer Kundenprojekte eine zentrale Rolle spielen.

## Was heißt das für unsere Kunden?

✅ Bestehende Angular-Projekte lassen sich **gezielt und sicher auf Angular 20 migrieren**  
✅ Neue Projekte setzen wir gerne direkt mit Angular 20 auf  
✅ Wir beraten, ob **SSR oder Zoneless Architecture** für dein Projekt sinnvoll sind

##### Offizielle Release-Dokumentation

- [Offizieller Angular Blog: Angular 20 Announcement](https://blog.angular.dev/announcing-angular-v20-b5c9c06cf301)

Du planst ein neues Angular-Projekt oder möchtest bestehende Anwendungen modernisieren?  
**Lass uns sprechen – wir unterstützen dich gerne.**


Angular 20 – die Jubiläumsversion im Überblick


Für die meisten Entwickler ist eine UUID einfach eine zufällige Zeichenkette, die als eindeutiger Schlüssel verwendet wird. Doch hinter einer UUID kann mehr stecken, als
nur ein paar zufällige Zeichen. Lasst uns das "Rabbit-Hole" der UUIDs erkunden und uns die verschiedenen Versionen ansehen.

# Welche UUID Versionen gibt es?

Es gibt insgesamt 8 verschiedene Versionen von UUIDs, die in der Spezifikation [RFC 9562](https://tools.ietf.org/html/rfc9562) definiert sind.
Höhere Versionen sind nicht unbedingt besser als niedrigere Versionen, sondern dienen dazu, verschiedene Anwendungsfälle zu unterstützen.

### Version 1

[UUID Version 1 (v1)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-1) wird aus der MAC-Adresse des Computers und der aktuellen Zeit generiert.
Somit kann aus diesem UUID-Typ abgeleitet werden, wann und wo die UUID generiert wurde. Dies kann für einige Anwendungsfälle nützlich sein, aber auch ein Sicherheitsrisiko darstellen.

### Version 2

[UUID Version 2 (v2)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-2) ist reserviert für [DCE](https://de.wikipedia.org/wiki/Distributed_Computing_Environment)-Sicherheits-UUIDs.

### Version 3

[UUID Version 3 (v3)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-3) werden aus MD5-Hashes generiert. Als Basis können beliebige Werte verwendet werden.
Häufig werden damit URLs oder andere eindeutige Schlüssel in UUIDs umgewandelt.

Achtung! Verwende diese Version nicht, wenn du sensible Informationen (z.B.: Passwörter) in der UUID speichern möchtest, da MD5 als unsicher gilt.

### Version 4

[UUID Version 4 (v4)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-4) sind rein zufällige UUIDs. Diese Version ist die am häufigsten verwendete Version von UUIDs.
Sie enthalten keinerlei Informationen über den Ersteller oder den Zeitpunkt der Erstellung.

Diese Version ist am besten geeignet, wenn eine zufällige ID benötigt wird. Somit sollte sie als **Standard** verwendet werden, wenn keine speziellen Anforderungen bestehen.

<div className="text-center w-full mb-6">
  <img
    className="max-h-64 m-auto"
    alt="UUIDv4 - Zufällige IDs sind am besten geeignet, wenn keine speziellen Anforderungen bestehen."
    src="/images/blog/8-verschiedene-uuids/uuids.png"
  />
</div>

### Version 5

[UUID Version 5 (v5)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-5) werden aus SHA-1-Hashes generiert. Ähnlich wie bei Version 3 können beliebige Werte als Basis verwendet werden.

Achtung! Verwende diese Version nicht, wenn du sensible Informationen (z.B.: Passwörter) in der UUID speichern möchtest, da SHA-1 als unsicher gilt.

### Version 6

[UUID Version 6 (v6)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-6) fast identisch mit Version 1, jedoch ist die Reihenfolge vertauscht damit die IDs leichter
nach Datum sortiert werden können.

### Version 7

[UUID Version 7 (v7)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-7) kombiniert zufällige Daten (wie in Version 4) mit einem Zeitstempel. Somit wird ein
sortierbarer UUID generiert ohne sensible Informationen wie die MAC-Adresse zu enthalten.

Diese Version ist nützlich, wenn eine UUID benötigt wird, die sortierbar sein soll, z.B. für Datenbanken. Da die MAC-Adresse nicht enthalten ist, ist sie "sicherer" als Version 1.

### Version 8

[UUID Version 8 (v8)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-8) eine Anwendungsspezifische UUID. In dieser Version hat der Ersteller
die Freiheit wie er die UUID generieren möchte.

# Wann sollte ich nun welche Version verwenden?

Mit 8 verschiedenen Versionen von UUIDs kann es schwer sein, die richtige Version für den jeweiligen Anwendungsfall zu finden. Es gibt jedoch einige Faustregeln, die dir helfen können.

- Meistens wird Version 4 als Standard verwendet, wenn eine zufällige UUID benötigt wird. Falls du einfach eine ID benötigst, verwende Version 4.
- Falls die ID sortierbar sein soll, verwende Version 7. Diese Version enthält einen Zeitstempel, der es ermöglicht, die UUIDs nach Datum zu sortieren.
- v5 oder v8 können verwendet werden, um eigene Daten darin zu verpacken. Diese Versionen sind jedoch weniger verbreitet und sollten nur verwendet werden, wenn du genau weißt, was du tust.

Wenn dieser Post dir geholfen hat, teile ihn mit deinen Kollegen. Falls du Fragen hast, schreibe mir gerne eine <a href="mailto:adrian.natter@fortix.io">E-Mail</a>.


UUID Versionen: Welche gibt es und wann sollte ich welche verwenden?


Softwareprojekte können schnell komplex und unüberschaubar werden. Der Druck, Features schnell zu liefern und Deadlines einzuhalten, führt oft dazu, dass die Qualität vernachlässigt wird. Die Konsequenzen sind gravierend: Bugs häufen sich, Nutzer werden unzufrieden, und technische Schulden wachsen. Was kurzfristig Zeit spart, wird langfristig teuer.

**Die Lösung? Effektives Qualitätsmanagement.** Es gewährleistet nicht nur stabile Software, sondern macht sie auch wartbar, skalierbar und nachhaltig erfolgreich. Dabei geht es weit über starre Regeln oder reines Testen hinaus – im Kern stehen durchdachte Prozesse, klare Rollenverteilungen und das richtige Mindset im gesamten Entwicklungszyklus.

#### Warum Qualitätsmanagement der entscheidende Faktor ist

Fehlerhafte Software kostet. Nicht nur in Form von Zeit und Geld, sondern auch in verlorenem Vertrauen. Kunden erwarten Anwendungen, die reibungslos funktionieren, benutzerfreundlich sind und mit wachsenden Anforderungen Schritt halten. Ohne gezieltes Qualitätsmanagement entwickelt sich Software schnell zu einer problematischen Baustelle.

Qualitätsmanagement hat einen klaren Mehrwert:

- **Frühzeitige Fehlererkennung**: Probleme früh im Entwicklungsprozess zu beheben ist effizienter und kostengünstiger. Dies verhindert aufwändige Nachbesserungen und hält den Projektplan auf Kurs.
- **Langfristige Wartbarkeit**: Sauberer, hochwertiger Code lässt sich einfacher erweitern und verbessern. Das spart Zeit bei künftigen Entwicklungen und senkt die Wartungskosten.
- **Stabile Releases**: Gründlich getestete Software schafft Zuverlässigkeit und Vertrauen bei den Anwendern. Ein stabiler Release-Zyklus stärkt die Kundenbindung und entlastet das Entwicklerteam.

Doch was macht Qualitätsmanagement wirklich **effektiv?**

#### Die Bausteine eines effektiven Qualitätsmanagements

Effektives Qualitätsmanagement besteht aus mehreren ineinandergreifenden Elementen. Wir setzen auf drei zentrale Bausteine: **Prozesse**, **Automatisierung** und **Verantwortung**. Nur wenn diese drei Bereiche harmonisch zusammenspielen, entsteht ein nachhaltiges System.

**1. Prozesse: Fehlervermeidung beginnt im Workflow**

Qualitätsmanagement startet nicht erst beim Testen – es beginnt bei der ersten Codezeile. Unsere Prozesse machen Qualität zum integralen Bestandteil der Entwicklung:

- **Strikte Pull-Request-Reviews**: Jede Code-Änderung durchläuft einen gründlichen Review. Dabei prüfen wir Funktionalität, Code-Qualität und Architektur. Diese Reviews verbessern nicht nur den Code, sondern dienen auch als Lernplattform für alle Entwickler. Das Vier-Augen-Prinzip ist hierfür integral.
- **Code kritisch hinterfragen**: Ist der Code zukunftsfähig? Erleichtert er spätere Erweiterungen? Ein guter Review geht über die reine Funktionalität hinaus und stellt sicher, dass der Code auch nach Monaten noch verständlich und wartbar ist.
- **Klare Teststrategie**: Eine durchdachte Teststrategie definiert, welche Features wie und von wem getestet werden. Das spart langfristig Ressourcen und minimiert das Risiko übersehener Fehler. Ausschlaggebend ist hierbei eine gesamtheitliche Teststrategie, bei der alle an Board sind: Produktmanagement, Product Owner und Entwickler.

**2. Automatisierung, die Qualität sichert**

Tools helfen uns, Qualität systematisch sicherzustellen und Fehler zu minimieren:

- **Unit- und Integrationstests**: Damit testen wir die Business-Logik unserer Anwendungen. Diese Tests gewährleisten, dass einzelne Module korrekt funktionieren und nahtlos zusammenarbeiten.
- **End-to-End-Tests mit Cypress**: Wichtige Anwendungsfälle werden automatisiert getestet – besonders die kritischen Features, die manuell nicht immer leicht oder nur zeitaufwändig abzusichern sind. Das steigert die Zuverlässigkeit und reduziert das Risiko von Regressionsfehlern. Gezielte End-To-End-Tests entlasten das Testing Team und garantieren die Funktionalität der Core Features.
- **SonarCloud-Scans**: Unsere CI/CD-Pipeline analysiert den Code und setzt ein **Quality Gate** für Clean Code, Test Coverage und Best Practices. Automatisierte Scans erkennen potenzielle Probleme früh und verbessern die Code-Qualität kontinuierlich.
- **Performance-Tests mit k6**: Bei Bedarf führen wir Lasttests durch, um Skalierbarkeit und Stabilität zu prüfen. So stellen wir sicher, dass die Software auch bei wachsender Nutzerzahl zuverlässig bleibt.

**3. Verantwortung: Qualität ist Teamsache**

Qualitative Software lebt von der gemeinsamen Verantwortung im Team. Klare Rollenverteilung schafft Orientierung:

- **Entwickler**: Sie verantworten das Testing ihrer User Stories und vermeiden Regressionen. Ihr Code muss den Anforderungen entsprechen und darf keine unerwarteten Seiteneffekte verursachen.
- **Product Owner**: Sie gewährleisten, dass die Anwendung die Qualitätsstandards und Anforderungen erfüllt. Sie behalten den Überblick über das Gesamtsystem und priorisieren Tests und Features.
- **Automatisierte Tests**: Sie sichern kritische Features ab, die manuell schwer zu testen sind. Als Sicherheitsnetz reduzieren sie den Aufwand für wiederkehrende Prüfungen.

Nur wenn jeder seine Rolle kennt und wahrnimmt, funktioniert das Qualitätsmanagement.

#### Herausforderungen: Warum gute Qualität kein Selbstläufer ist

Effektives Qualitätsmanagement erfordert Zeit, Disziplin und klare Strukturen. Die größten Herausforderungen:

- **Unklare Verantwortlichkeiten**: Ohne eindeutige Zuständigkeiten entstehen Lücken, und wichtige Tests bleiben aus. Klar definierte Verantwortlichkeiten stellen sicher, dass alle wichtigen Aspekte geprüft werden.
- **Fokus auf kurzfristige Ergebnisse**: Tests und Reviews brauchen Zeit – sparen langfristig aber noch mehr. Teams, die nur schnelle Erfolge suchen, riskieren technische Schulden, die später teuer werden können.
- **Fehlende Teststrategie**: Die Entscheidung zwischen automatisierten und manuellen Tests braucht Struktur. Ein durchdachter Plan hilft, Ressourcen effizient einzusetzen und die Team-Effizienz zu steigern.

Unsere Erfahrung zeigt: Mit klaren Prozessen und einer gemeinsamen Qualitätsvision lässt sich jede dieser Herausforderungen meistern.

#### Warum effektives Qualitätsmanagement den Projekterfolg sichert

Qualitätsmanagement bedeutet nicht nur Fehlerbehebung – es verhindert ihr Entstehen. Dies garantiert, dass:

- **Software stabil und zuverlässig ist.** Durchdachte Tests und regelmäßige Code-Reviews stellen sicher, dass Änderungen die bestehende Funktionalität nicht beeinträchtigen.
- **Technische Schulden minimiert werden.** Die konsequente Einhaltung von Best Practices und automatisierte Qualitätskontrollen sichern langfristige Wartbarkeit.
- **Kunden und Nutzer Vertrauen aufbauen.** Zuverlässige, fehlerfreie Software steigert die Nutzerzufriedenheit und stärkt das Vertrauen ins Produkt.
- **Teams effizienter arbeiten können.** Strukturiertes Qualitätsmanagement reduziert Nacharbeit und schafft Raum für Innovation und Wachstum.

Erfolg in der Softwareentwicklung entsteht nicht von selbst. Projekte gelingen, wenn Qualität zur Entwicklungskultur wird. Mit durchdachten Prozessen, der richtigen Toolchain und klaren Verantwortlichkeiten schaffen wir stabile und zukunftssichere Software.


Angular at Scale – Best Practices für Enterprise-Applikationen

Angular 20 – die Jubiläumsversion im Überblick

UUID Versionen: Welche gibt es und wann sollte ich welche verwenden?

Effektives Qualitätsmanagement: Der Schlüssel zu nachhaltigem Projekterfolg