QDA in der Praxis: Wie Du mit Quality-Driven Architecture robuste Angular-Anwendungen entwickelst

Ob in eigenen Projekten, den Medien oder Erfahrungsberichten anderer Software Engineers und -Architect:innen habe ich eines immer wieder gesehen: Ideen scheitern nicht an der Funktionalität, sondern an einer vernachlässigten Architektur.
Eine Anwendung, die heute funktioniert, aber kein solides Fundament aufweist, wird morgen zur Last. Sie wird langsam, fehleranfällig und kaum noch wartbar. Nicht selten endet das in einem Rewrite (der im Zweifel wieder in derselben Sackgasse landet) und dem Verlust der Mitarbeiter, die man nun am ehesten bräuchte, da diese immer wieder darauf hingewiesen haben.

Deshalb möchte ich heute das Thema Quality-Driven Architecture besprechen.

Es ist ein relativ leicht anzuwendendes Vorgehen. Wenn man so will, eine Art Kompass um Software und somit auch Angular-Anwendungen zu bauen, die nicht nur heute funktionieren, sondern auch in Zukunft stabil, schnell und erweiterbar bleiben.

Was heißt „qualitätsgetrieben“? Eine Analogie

Stell euch vor, ihr baut ein Haus. Die funktionalen Anforderungen sind klar: Es braucht ein Dach, Wände, eine Küche, ein Bad und eine Garage. Das ist das „Was“. Aber jetzt kommen die entscheidenden Fragen, die Qualitätsfragen – das „Wie gut“:

• Wie gut soll das Haus gedämmt sein, damit die Heizkosten niedrig bleiben? (Performance & Effizienz)
• Wie sicher sollen die Schlösser sein? (Sicherheit)
• Wie einfach soll es sein, später einen Wintergarten anzubauen? (Wartbarkeit & Erweiterbarkeit)
• etc.

Genau das Gleiche tun wir in der qualitätsgetriebenen Softwarearchitektur. Wir definieren von Anfang an, welche Qualitätsmerkmale für unser Projekt relevant sind. Diese Ziele leiten dann jede unserer Entscheidungen. Das Schöne daran: Diese Ziele sind meist schon deutlich vor den konkreten, funktionalen Anforderungen definierbar und mit den Stakeholdern verhältnismäßig schnell zu ermitteln.

Essenziell für ein Qualitätsziel ist, dass es Messbar ist. Denn nur was messbar ist, kann man monitoren, erreichen oder verbessern.

---

Ein wichtiger Werkzeugkoffer: Die Qualitätsziele von arc42

Um diese Ziele greifbar zu machen, orientieren wir uns am praxiserprobten Modell von arc42. Es hilft uns, Klarheit zu schaffen und im Team die gleiche Sprache zu sprechen. Außerdem können wir uns an weit über 100 Zielen und Beispielen abarbeiten oder sie durchsuchen und Szenarien hierfür durchdenken. Es beinhaltet auch die Qualitäten aus ISO-25010.

1. Laufzeitqualität: Was der Benutzer erlebt

Hier geht es um alles, was während der Ausführung der Anwendung spürbar und gleichzeitig messbar ist.

• 🚀 Performance & Effizienz: Die Geschwindigkeit ist oft der erste und wichtigste Eindruck und sie kostet im Zweifel Umsatz.

  • Messbares Ziel-Szenario: "Die Produktdetailseite muss bei einer simulierten 'Fast 3G'-Netzwerkverbindung einen Largest Contentful Paint (LCP) von unter 2,5 Sekunden erreichen, gemessen mit Lighthouse-Tools im CI/CD-Prozess."
  • ➡️ Architektonische Antwort in Angular:
  • Lazy Loading: Wir laden nicht die gesamte App auf einmal, sondern nur die Teile, die der Nutzer gerade braucht. Bei einem E-Book beispielsweise laden wir nicht den gesamten Inhalt, stattdessen laden wir nur die aktuelle Seite oder ggf. ein Kapitel. Dies ist mit den modernen Standalone Components und weiteren Mitteln wie Lazy-Routing und @defer in Angular ein Kinderspiel.
  • NgOptimizedImage: Bilder sind oft die größten Performance-Fresser. Diese spezielle Direktive ist wie ein intelligenter Assistent, der sicherstellt, dass Bilder erst geladen werden, wenn sie sichtbar werden, und das in der optimalen Größe.

• 🔐 Sicherheit (Security): Das Vertrauen unserer Nutzer ist ein hohes Gut.

  • Messbares Ziel-Szenario: "Bei einem automatisierten Security-Scan mit OWASP ZAP als Teil des Nightly-Builds dürfen keine neuen 'High'- oder 'Medium'-Alerts für Cross-Site Scripting (XSS) oder Cross-Site Request Forgery (CSRF) im Frontend-Scope auftreten."
  • ➡️ Architektonische Antwort in Angular:
  • Angulars eingebauter Schutz: Das Framework ist hier Ihr stärkster Verbündeter. Es bereinigt standardmäßig alle Eingaben, bevor sie auf der Seite angezeigt werden und schützt so automatisch vor gängigen Angriffen wie Cross-Site Scripting (XSS).

• 🤝 Zuverlässigkeit (Reliability): Die Anwendung muss auch dann stabil bleiben, wenn mal etwas schiefgeht.

  • Messbares Ziel-Szenario: "Antwortet der API-Endpunkt für Produktempfehlungen mit einem Error HTTP-Status 503 (Service Unavailable), muss die Seite ohne JavaScript-Fehler weiterlaufen und die definierte Fallback-Komponente ('Empfehlungen konnten nicht geladen werden') wird innerhalb von 500ms angezeigt."
  • ➡️ Architektonische Antwort in Angular:
  • Fehlerbehandlung in Services: Wir fangen Fehler dort ab, wo sie entstehen – meist bei der Kommunikation mit dem Server (Backend). Mit dem RxJS-Operator catchError können wir einen Fehler beispielsweise elegant abfangen und einen stabilen Zustand (z.B. eine leere Liste) an die Komponente weitergeben, damit die UI nicht in einen Error-State gelangt.

2. Entwicklungsqualität: Unser Alltag als Entwickler

Diese Ziele sorgen dafür, dass die Arbeit an der Codebasis effizient und möglichst frustfrei bleibt.

• ⚙️ Wartbarkeit (Maintainability): Der Code muss auch in sechs Monaten noch verständlich und einfach zu ändern sein. Das ist vielleicht das wichtigste Ziel für die Langlebigkeit eines Projekts.

  • Messbares Ziel-Szenario: "Die zyklomatische Komplexität jeder Methode innerhalb von Angular-Services und -Komponenten, gemessen durch Tools wie SonarQube, darf den Wert 10 nicht überschreiten. Neue Pull Requests, die diesen Schwellenwert verletzen, werden automatisch blockiert."
  • ➡️ Architektonische Antwort in Angular:
  • Organisation nach Features: Wir gruppieren Code nicht nach Typ (alle Services in einem Ordner), sondern nach fachlicher Zuständigkeit (alles zum Thema „User“ in einem Ordner). So ist alles, was zusammengehört, auch beisammen.
  • Trennung in „Smart“- und „Dumb“-Komponenten: Dieses Muster ist Gold wert.
    • Smart: Die Komponente, die weiß, was zu tun ist. Sie spricht mit den Services und holt Daten.
    • Dumb: Eine dumme, aber hübsche Komponente, die nur Daten entgegennimmt und anzeigt. Sie ist wiederverwendbar und einfach zu verstehen.

• 📋 Testbarkeit (Testability): Vertrauen ist gut, testen ist besser.

  • Messbares Ziel-Szenario: "Die Code-Abdeckung (Code Coverage) durch Unit-Tests für alle einer neuen Unit muss bei mindestens 85 % liegen und soll innerhalb von 30 Minuten erreicht werden können. Dieser Wert wird bei jedem Commit geprüft und darf nicht sinken."
  • ➡️ Architektonische Antwort in Angular:
  • Logik in Services auslagern: Eine wichtige Regel für gute Testbarkeit! Komponenten-Code ist schwerer zu testen. Logik, die in einem einfachen TypeScript-Service steckt, kann hingegen leicht mit Unit-Tests überprüft werden. Angulars Dependency Injection hilft uns dabei, diese Services in unseren Tests durch Mocks zu ersetzen.
  • Test Driven Development (TDD): Tests schreiben, bevor die eigentliche Logik implementiert wird. So stellt man sicher, dass jede neue Funktionalität von Anfang an abgedeckt ist und erreicht idR. eine gut testbare Struktur und die gewünschte Coverage fast automatisch.

3. Betriebsqualität: Die Anwendung im Live-Betrieb

Wenn die Anwendung live ist, wollen wir wissen, was passiert.

• 📊 Betrieb & Monitoring (Operations): Blind im Produktivsystem zu agieren, ist wie Autofahren bei Nacht ohne Licht.
  • Messbares Ziel-Szenario: "Alle HTTP-Anfragen, die eine Antwortzeit von über 800 ms aufweisen, müssen automatisch ein Event im Monitoring-Tool auslösen, das die genaue URL, die Dauer und die User-ID enthält."
  • ➡️ Architektonische Antwort in Angular:
  • HttpInterceptor: Dies ist ein mächtiges Werkzeug in Angular. Wir können einen zentralen Interceptor für alle Server-Anfragen bauen. Dieser kann zum Beispiel messen, wie lange jede Anfrage dauert, und diese Information an ein externes Monitoring-Tool (z.B. Sentry, Datadog o.Ä.) senden. So bemerken wir Performance-Probleme, bevor Nutzer sich beschweren.

---

Fazit

Qualitätsgetriebene Architektur ist kein Hexenwerk. Es ist die bewusste Entscheidung, von Anfang an über das „Wie gut“ nachzudenken. Sprecht mit euren Teams und Auftraggeber:innen über diese Ziele. Priorisiert sie! Ein kleines internes Tool braucht vermutlich nicht die gleiche Ausfallsicherheit wie ein Online-Shop.

Wenn diese Prinzipien verinnerlicht werden, werdet ihr nicht nur bessere Anwendungen bauen. Ihr werdet auch zu besseren Architekt:innen, die vorausschauend planen und Systeme erschaffen, die Freude machen – bei der Nutzung und bei der Weiterentwicklung.
Fangt klein an, wählt zwei oder drei Qualitätsziele für die nächsten Features und wendet ggf. auch welche der oben genannten Muster an. Ihr werdet den Unterschied spüren und bitte auch messen.