Katalog
concept#Architektur#Software‑Engineering#Integration#Plattform

Microfrontends

Architekturmuster zur Zerlegung großer Web‑Frontends in eigenständige, unabhängig deploybare Teilanwendungen pro Team.

Microfrontends zerlegen monolithische Web‑Frontends in eigenständige, unabhängig deploybare Teilapplikationen, die von verschiedenen Teams entwickelt werden können.
Etabliert
Hoch

Klassifikation

  • Hoch
  • Organisatorisch
  • Architektur
  • Fortgeschritten

Technischer Kontext

CI/CD (Jenkins, GitHub Actions)CDN + Edge‑CachingObservability (Tracing, RUM)

Prinzipien & Ziele

Klare Domänen‑Grenzen definierenTeams besitzen End‑to‑end‑VerantwortungSchnittstellen als Verträge behandeln
Umsetzung
Unternehmen, Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Fragmentierung der Nutzererfahrung
  • Performance‑Einbußen durch Komposition und Laden
  • Wachsende Betriebskosten durch mehrere Pipelines
  • Etablieren gemeinsamer Schnittstellenverträge
  • Zentrale UX‑Guidelines und visuelle Tokens
  • Automatisierte End‑to‑End‑Tests über Grenzen hinweg

I/O & Ressourcen

  • Modulare Domänenaufteilung und APIs
  • Automatisierte CI/CD‑Pipelines
  • Shared Design‑System und UX‑Standards
  • Unabhängig deploybare UI‑Module
  • Klar definierte Schnittstellen und Verträge
  • Metriken zu Release‑Frequenz und Performance

Beschreibung

Microfrontends zerlegen monolithische Web‑Frontends in eigenständige, unabhängig deploybare Teilapplikationen, die von verschiedenen Teams entwickelt werden können. Die Methode fördert Autonomie, isolierte Releases und technologische Vielfalt. Gleichzeitig entstehen Integrations-, Performance- und UX‑Verantwortungen, die koordiniert werden müssen. Governance, Testing und gemeinsame Schnittstellen sind entscheidend für erfolgreiche Adoption.

✔

  • Erhöhte Teamautonomie und unabhängige Releases
  • Gezielte technologische Evolution pro Domäne
  • Skalierbare Organisationsstruktur für große Frontends

✖

  • Erhöhter Integrationsaufwand und Komplexität
  • Höherer Overhead bei Shared‑UX und Konsistenz
  • Nicht sinnvoll für sehr kleine Anwendungen

  • Release‑Frequenz pro Microfrontend

    Messt, wie oft einzelne Microfrontends getrennt deployed werden.

  • Time‑to‑Restore (Frontend‑Incidents)

    Durchschnittliche Wiederherstellungszeit nach einem Frontend‑Ausfall.

  • Perceived‑UI‑Consistency Score

    Qualitativer Messwert für UX‑Kohärenz über Microfrontends hinweg.

Spotify‑ähnliche Feature‑Teams

Getrennte Feature‑Teams entwickeln isolierte UI‑Module, die über einen Shell‑Kompositor zusammenlaufen.

E‑Commerce Domain‑Split

Produktdetail, Warenkorb und Checkout laufen als eigenständige Microfrontends mit eigenen Deploys.

Legacy‑Migration

Altes SPA wird schrittweise in Microfrontends zerlegt, um riskante Big‑Bang‑Releases zu vermeiden.

1

Analysiere Domänen und definiere Ownership

2

Implementiere Composition‑Layer und Routing

3

Richte CI/CD, Testing und Observability pro Microfrontend ein

4

Iteriere und erweitere die Modularisierung schrittweise

⚠️ Technische Schulden & Engpässe

  • Mehrere Build‑Pipelines ohne Standardisierung
  • Veraltete Shared‑Libraries, die nicht synchronisiert werden
  • Unzureichende Observability für zusammengesetzte Flows
Shared‑State ManagementCross‑Team TestingUI‑Kohärenz
  • Aufteilung nur nach technischen Präferenzen, nicht nach Domänen
  • Jedes Team verwendet komplett inkompatibles Tooling ohne Adapter
  • Verzicht auf gemeinsame Tests und Kontraktrückverfolgung
  • Unterschätzen der Cross‑Team‑Koordination
  • Performance‑Schulden durch zu viele Laufzeit‑Anfragen
  • Versteckte Abhängigkeiten zwischen Microfrontends
Frontend‑Architektur und Module‑FederationCI/CD‑Pipelines und Deployment‑AutomatisierungCross‑Team‑Koordination und API‑Design
Teamautonomie und Release‑UnabhängigkeitSkalierbarkeit der EntwicklerorganisationNotwendigkeit für inkrementelle Migration
  • • Browser‑Ladezeiten und Initial‑Bundle‑Größe
  • • Organisatorische Reife für Governance
  • • Notwendigkeit klarer Schnittstellenverträge