Über diese Seite
frontend-architekt.de beschäftigt sich mit Frontend-Architektur in größeren Anwendungen.
Im Mittelpunkt stehen nicht einzelne Framework-Tricks, sondern die Frage, wie Frontends langfristig verständlich, wartbar und veränderbar bleiben können.
Denn moderne Frontends sind längst mehr als Oberfläche.
Sie verwalten komplexen Zustand. Sie bilden fachliche Regeln ab. Sie integrieren APIs. Sie berücksichtigen Rollen, Rechte und Sicherheitsanforderungen. Sie müssen getestet, betrieben, beobachtet und über Jahre weiterentwickelt werden.
Frontend ist damit harte Applikationsentwicklung.
Und gute Frontend-Entwicklung braucht mehr als Komponenten, Styling und Tooling.
Sie braucht klare Verantwortung, fachliche Schnitte, technische Disziplin und ein gemeinsames Verständnis davon, wo Architektur im Code sichtbar wird.
Blick auf Architektur
Abschnitt betitelt „Blick auf Architektur“Der Schwerpunkt dieser Seite liegt im Frontend.
Trotzdem endet moderne Frontend-Architektur selten an der Komponentengrenze.
Sie berührt Build-Systeme, Monorepos, APIs, Deployment-Strategien, Teamgrenzen, fachliche Schnitte, Testbarkeit, Observability und manchmal auch die Frage, ob ein System überhaupt sinnvoll geschnitten ist.
Deshalb geht es hier nicht nur um Komponenten, Stores und UI-Patterns, sondern auch um größere Systemzuschnitte:
- Self-contained Systems
- Microfrontends
- Module Federation
- API- und Service-Grenzen
- Event-getriebene Kommunikation
- Preview-/Branch-Deployments
- CI/CD in Nx-Monorepos
- Architektur in regulierten Kontexten
- Integration von LLMs und agentischen Entwicklungsflüssen
Frontend bleibt der Ausgangspunkt.
Aber viele wichtige Architekturfragen entstehen dort, wo Frontend, Backend, Teamstruktur und Deployment aufeinandertreffen.
Technischer Kontext
Abschnitt betitelt „Technischer Kontext“Viele Beispiele und Gedanken auf dieser Seite kommen aus modernen TypeScript- und Angular-Ökosystemen.
Dazu gehören unter anderem:
- Angular in größeren Enterprise-Setups
- Nx Monorepos und klare Projektgrenzen
- Module Federation und Micro-Frontend-Architekturen
- Self-contained Systems als fachlich geschnittene Systembausteine
- Domain-Driven Design im Frontend
- vertikale Schnitte statt technischer Ordnerfriedhöfe
- NgRx, Signal Store und reaktive Datenflüsse
- NestJS und API-Gateways im TypeScript-Umfeld
- E2E-Strategien mit Playwright
- Branch-/Preview-Deployments
- Docker, Traefik und GitLab CI/CD
- Architektur in regulierten Kontexten
- LLM-Integration als eigener Service
Tools stehen dabei nicht im Mittelpunkt.
Tools sind nur dann hilfreich, wenn sie gute Schnitte unterstützen.
Ein Store löst kein State-Problem, wenn niemand weiß, welcher Zustand fachlich relevant ist. Ein Microfrontend macht kein Team autonom, wenn die fachlichen Grenzen fehlen. Ein Monorepo ist keine Architektur, wenn alles mit allem sprechen darf. Ein Self-contained System ist kein Gewinn, wenn Verantwortung, Daten, UI und Betrieb nicht zusammen gedacht werden.
Haltung
Abschnitt betitelt „Haltung“Diese Seite betrachtet Architektur nicht als Selbstzweck.
Architektur soll Teams entlasten. Sie soll Entscheidungen nachvollziehbar machen. Sie soll Veränderung ermöglichen. Sie soll verhindern, dass jedes neue Feature zur Grabung durch implizites Wissen wird.
Gute Architektur macht Systeme nicht automatisch einfach.
Aber sie macht Veränderung weniger zufällig.
Sie hilft, fachliche Verantwortung sichtbar zu machen. Sie reduziert unnötige Kopplung. Sie schafft Orte für Entscheidungen. Sie macht Fehler früher erkennbar. Und sie gibt Teams eine gemeinsame Sprache für technische und fachliche Probleme.
Themen dieser Seite
Abschnitt betitelt „Themen dieser Seite“frontend-architekt.de ist ein öffentliches Arbeitsbuch zu Frontend-Architektur.
Hier entstehen Texte über Haltungen, Patterns, Anti-Patterns, Architekturentscheidungen und typische Probleme aus realer Projektarbeit.
Nicht als neutraler Best-Practices-Katalog. Nicht als Framework-Fanclub. Nicht als Marketing-Funnel.
Sondern als Versuch, Frontend-Architektur so zu beschreiben, wie sie in echten Projekten häufig sichtbar wird:
technisch, organisatorisch, manchmal unbequem — aber immer mit dem Ziel, Systeme verständlicher, wartbarer und veränderbarer zu machen.
Kontakt
Abschnitt betitelt „Kontakt“Kontakt: