Architecting Angular Applications - Teil 1: Einführung

Veröffentlicht am 18. Juni 2024 - ⏱️ Ca. (wird berechnet) min. Lesezeit

Warum diese Serie?

Seit meinen ersten Projekten mit Angular fällt mir auf: Entwickler hangeln sich von Feature zu Feature, ohne eine tragfähige Struktur aufzubauen. Komponenten wachsen, Services verkommen zu Allzweckhalden. Die UI trägt zu viel Verantwortung, Architektur zu wenig. Der Fokus bleit gerne rein auf Features und Framework-Eigenheiten. Dabei entscheidet gerade die architektonische Gestaltung über die langfristige Qualität und Wartbarkeit einer Anwendung. Tutorials erklären einzelne Features, Stack Overflow bzw. GPT hilft bei akuten Problemen. Aber wie daraus ein System entsteht, das auch in zwei Jahren noch wartbar ist, das bleibt oft offen. Genau hier setzt diese Serie an.

So wachsen viele Anwendungen, ohne dabei wirklich zu reifen. UI-Komponenten übernehmen ganze Anwendungsfälle. Services werden systematisch under- oder overused. Pipes sind noch eine der robustesten Eigenheiten von Angular. Hier sieht man kaum Fehler. Direktiven sehen da wieder ganz anders aus. Manch einer muss jetzt vielleicht erstmal kurz überlegen, was eine Direktive nochmal genau ist. Architektur ergibt sich nebenbei, anstatt bewusst gestaltet zu werden.

Oft werde ich gefragt: Wie würdest du es machen? Nun, ganz so einfach ist es nicht. Statt Kochrezepten braucht es Prinzipien. Architektur ist keine Pattern-Sammlung, sondern eine Denkhaltung. Wer Angular nachhaltig einsetzen will, muss lernen, zwischen Darstellung, Ablauf und Verantwortung zu unterscheiden. Genau diese architektonische Denkweise, die hilft, bewusste Strukturentscheidungen im UI- und Applikationsdesign zu treffen möchte diese Serie vermitteln.

Sie richtet sich an alle, die Angular nicht nur verwenden, sondern ihre Anwendungen gezielt strukturieren und gestalten wollen. Ohne blind Patterns zu übernehmen. Ohne die nächste generierte Lösung unreflektiert einzubauen. Sondern mit einem eigenen, belastbaren Architekturverständnis.

Diese Serie will kein akademisches Theoriekonstrukt liefern, sondern praxisnahe Orientierung für tragfähige Architekturentscheidungen im Alltag:

Ein wichtiger Teil dieser Orientierung ist das bewusste Erkennen und Vermeiden typischer Anti-Patterns, die sich in Angular-Projekten allzu leicht einschleichen. Gerade durch das Verständnis dieser Fallstricke entsteht erst der architektonische Blick, den diese Serie vermitteln will.

• Wann ist eine Direktive sinnvoll und wann nicht?
• Welche Verantwortung hat eine Component wirklich?
• Wie bringe ich Struktur in komplexe Anwendungsfälle, ohne sie unübersichtlich oder starr werden zu lassen?
• Welche Muster haben sich in der Praxis bewährt und welche Entscheidungen führen oft zu langfristigen Architekturproblemen?

Mein Ziel ist es, Werkzeuge an die Hand zu geben, mit denen der Weg von der reinen Framework-Nutzung hin zur aktiven Architekturgestaltung gelingt. Damit man am Ende nicht nur weiss, wie man Angular einsetzt, sondern auch versteht, welche architektonischen Entscheidungen dahinterstehen und wie sie die Qualität der Anwendung langfristig prägen.

Diese Serie beginnt bei den sichtbaren Bausteinen wie Components und Directives. Später arbeitet sie sich Schicht für Schicht in die Tiefe vor. Es folgen Services, State-Management und domänennahe Architekturprinzipien. Gerade Services haben sich in vielen Angular-Projekten zu einer Art "God-Entität" entwickelt. Was nicht klar zugeordnet ist, landet schnell im Service. Genau hier entstehen viele der späteren Wartbarkeitsprobleme. Und auch wenn es viele nicht auf dem Schirm haben: Es gibt Alternativen.

Frameworks wie Django reizen den Entwickler bewusst Architektur zu leben und zu hinterfragen. In der Angular Gemeinschaft scheint es eher optional und pragmatisch zu sein, sich mit Architektur auseinanderzusetzen. Leider habe ich schon Aussagen gehört, wie eine Angular-Anwendung sei ohnehin in wenigen Jahren obsolet und werde dann neu gemacht. Doch diese Haltung ist eine selbst erfüllende Prophezeiung. Wer auf klare Architektur verzichtet, sorgt unweigerlich dafür, dass die Anwendung so unwartbar wird, dass tatsächlich nur noch ein Neuprojekt bleibt. Der im Management verhasste Satz ist dann vorprogrammiert: „Wir müssen es neu machen.“

Im späteren Teil der Serie werde ich mich intensiv damit befassen, wie moderne Architekturprinzipien, etwa aus dem Domain-Driven Design, sinnvoll in Angular-Projekte integriert werden können. Mit dem Ziel, eine Struktur zu schaffen, die auch unter wachsender Komplexität tragfähig bleibt.

Ein weiterer Vorteil: Mit durchdachter Architektur lässt sich beim Neubau einer Angular-Anwendung ein grosser Teil der bestehenden Applikations- und Business-Logik direkt weiterverwenden. Ein Neubau wird damit nicht zum Neuanfang, sondern zu einem gut planbaren Modernisierungsschritt.

Architekt ist keine separate Berufsbezeichnung. Es ist eine entscheidende Teildisziplin innerhalb der täglichen Entwicklerarbeit. Kein "Architekt" kann eine Software retten. Nur ein Team, das Architektur gemeinsam denkt und verantwortet, schafft langfristig tragfähige und überzeugende Systeme. Diese Serie will genau dieses Architekturbewusstsein schärfen. Nicht abschliessend, aber als Einstieg in eine tiefere Auseinandersetzung. Als Grundlage für bessere Softwarequalität im Alltag.

Dem Leser sei ans Herz gelegt immer kritisch zu hinterfragen. Nicht jedes Pattern ist per se gut. Entscheidend ist, in welchem Kontext es sinnvoll ist und wie es zur Gesamtarchitektur einer Anwendung beiträgt.

PS: Über Feedback zu meinen Gedanken würde ich mich sehr freuen! Lob und konstruktive Kritik sehr gerne an kontakt@nicolaiwolko.ch. Gerne werde ich diese Serie in Zukunft pflegen und Feedback einarbeiten.