Wie groß sollte ein Microfrontend sein?

Das Wort „Microfrontend“ legt eine einfache Vorstellung nahe: Ein Microfrontend ist ein besonders kleines Frontend.

Daraus entstehen schnell Regeln, nach denen ein Remote nur wenige Komponenten enthalten, genau eine Route abbilden oder höchstens einen kleinen Ausschnitt der Oberfläche darstellen sollte. Manchmal wird seine Größe an Dateien, Funktionen, Bundle-Größe oder Zeilen Code gemessen.

Diese Werte können für Performance, Buildzeiten oder Wartbarkeit relevant sein. Sie beantworten jedoch nicht die strategische Frage, ob ein Bereich sinnvoll abgegrenzt und eigenständig verantwortbar ist.

Ein kleines Bundle kann fachlich schlecht geschnitten sein. Ein umfangreiches Remote kann dagegen eine klare und belastbare Grenze besitzen.

Die direkte Antwort auf die Frage nach der richtigen Größe lautet deshalb: Es kommt darauf an – aber nicht auf Zeilen Code, Komponenten, Routen oder Bildschirmfläche.

Ein Microfrontend sollte so groß sein wie der fachliche Veränderungsraum, den ein Team sinnvoll und weitgehend eigenständig verantworten kann.

„Micro“ beschreibt keine technische Maßeinheit

Bei Microservices hat sich früh die Frage verbreitet, wie viele Zeilen Code oder wie viele Endpunkte ein Service besitzen dürfe. Bei Microfrontends wiederholt sich dieselbe Diskussion mit Komponenten, Views und Bundles.

Das Präfix „Micro“ wirkt dabei wie eine Größenangabe, obwohl es keine belastbare Maßeinheit liefert. Es gibt keine Zahl, ab der ein Frontend zu groß für ein Microfrontend wird. Ebenso wenig wird eine technische Einheit allein durch geringe Größe zu einer sinnvollen fachlichen Grenze.

Ein Remote mit fünf Komponenten kann mehrere unverbundene Verantwortlichkeiten enthalten. Ein Remote mit hundert Komponenten kann einen einzigen zusammenhängenden Produktbereich abbilden.

Auch sichtbare Größe hilft kaum weiter. Eine kleine Karte in einem Dashboard kann einen eigenständigen fachlichen Bereich mit eigener Datenhaltung, eigenem Releasezyklus und klarer Verantwortung repräsentieren. Eine vollständige Seite kann dagegen nur ein Ausschnitt eines größeren fachlichen Ablaufs sein.

Die Größe eines Microfrontends lässt sich deshalb nicht aus seiner Oberfläche ablesen. Entscheidend ist, welche Verantwortung innerhalb seiner Grenze zusammengefasst wird.

Fachlicher Veränderungsraum statt Bildschirmfläche

Eine tragfähige Grenze umfasst Funktionen, die fachlich zusammengehören. Sie verwenden dieselbe Sprache, verändern sich aus ähnlichen Gründen und können von einem Team gemeinsam verstanden werden.

Die zentrale Leitfrage lautet:

Was ändert sich typischerweise gemeinsam – und was sollte unabhängig verändert werden können?

Funktionen gehören eher in dasselbe Microfrontend, wenn sie:

• dieselben fachlichen Begriffe und Regeln verwenden,
• aus ähnlichen fachlichen Gründen verändert werden,
• einen gemeinsamen und beherrschbaren Backend-Vertrag besitzen,
• vergleichbare Release- und Änderungszyklen haben,
• von demselben Team verstanden und verantwortet werden können,
• gegenüber benachbarten Bereichen eine erkennbare Grenze bilden.

Dabei ist fachliche Nähe wichtiger als räumliche Nähe.

Zwei Elemente können auf derselben Seite direkt nebeneinanderliegen und trotzdem zu unterschiedlichen Verantwortungsbereichen gehören. Umgekehrt kann ein fachlich zusammenhängender Bereich mehrere Seiten, Dialoge, Routen und Hintergrundprozesse umfassen.

Die Bildschirmaufteilung beschreibt die Komposition einer Oberfläche. Sie beschreibt nicht automatisch die fachliche Architektur dahinter.

Eine tiefe Domäne darf groß sein

Ein Kalender für eine Arztpraxis kann auf den ersten Blick wie eine einzelne Funktion wirken. Tatsächlich kann er einen erheblichen fachlichen Umfang besitzen.

Zur Kalenderdomäne können unter anderem gehören:

• Terminplanung und Terminverschiebung,
• Behandler, Räume und weitere Ressourcen,
• unterschiedliche Terminarten,
• Serien und Wiederholungsregeln,
• Sperrzeiten und Abwesenheiten,
• Konflikterkennung,
• Wartelisten,
• Stornierungen,
• Berechtigungen,
• verschiedene Kalenderansichten,
• fachliche Regeln für Verfügbarkeit und Auslastung.

Ein solcher Kalender ist weder technisch noch fachlich klein. Trotzdem kann er einen klaren fachlichen Raum bilden.

Seine Verantwortung lässt sich gegenüber Patientenakte, Abrechnung, Dokumentation, Benutzerverwaltung oder Kommunikation verständlich abgrenzen. Innerhalb des Kalenders greifen viele Regeln ineinander. Außerhalb seiner Grenze gelten andere Begriffe, andere Änderungsgründe und häufig auch andere Verantwortlichkeiten.

Der Kalender ist deshalb nicht zu groß, nur weil er tief ist.

Problematisch würde seine Grenze erst, wenn dasselbe Remote zusätzlich unabhängig veränderliche Bereiche wie Abrechnung, Patientenverwaltung und Dokumentation übernimmt. Dann wächst nicht nur die fachliche Tiefe. Vor allem wächst die Breite der Verantwortung.

Microfrontends begrenzen nicht zwingend die Tiefe einer Domäne. Sie begrenzen vor allem die Breite von Verantwortung und Koordination.

Eine tiefe Domäne darf groß sein, solange ihre äußere Grenze verständlich bleibt.

Wenn Remotes zu klein werden

Eine Kalenderseite lässt sich technisch problemlos in mehrere Remotes zerlegen:

Kalenderseite
├── Toolbar-Remote
├── Filter-Remote
├── Kalender-Remote
├── Detail-Remote
└── Aktions-Remote

Auf einem Architekturdiagramm kann diese Aufteilung sauber und modular aussehen. In der Nutzung bilden Toolbar, Filter, Kalender, Details und Aktionen jedoch möglicherweise einen einzigen fachlichen Ablauf.

Eine Filteränderung beeinflusst den Kalender. Eine Auswahl im Kalender öffnet die Details. Eine Aktion verändert den Termin und muss anschließend Kalender, Detailansicht und Rückmeldung aktualisieren. Fehler, Ladezustände und Berechtigungen betreffen mehrere Teile gleichzeitig.

Die technische Zerlegung erzeugt dann keine unabhängigen Veränderungsräume. Sie verteilt einen zusammenhängenden Ablauf lediglich über mehrere Artefakte.

Die Folgen sind häufig:

• zusätzliche Runtime-Abhängigkeiten,
• verteilter Zustand und aufwendige Synchronisation,
• fragmentierte Fehler- und Ladebehandlung,
• unklare Verantwortung für den gesamten Ablauf,
• kompliziertere Integrations- und End-to-End-Tests,
• langsamere lokale Entwicklung,
• mehr Build- und Deployment-Pipelines,
• gemeinsame Releases trotz getrennter Deployments,
• zusätzlicher Aufwand für Observability und Fehlersuche.

Ein separat deploybares Widget ist noch kein eigenständig verantwortbarer Produktbereich.

Das bedeutet nicht, dass kleine Remotes grundsätzlich falsch sind. Ein kleiner Bereich kann eine sehr gute Grenze besitzen, wenn er eine eigenständige fachliche Fähigkeit abbildet, einen klaren Verantwortlichen hat und unabhängig verändert werden kann.

Ein Reporting-Widget kann beispielsweise eine eigene Datenquelle, einen eigenen Releasezyklus und eine deutlich getrennte Verantwortung besitzen. Seine geringe sichtbare Größe spricht weder für noch gegen seine Eigenständigkeit.

Das Problem ist nicht die geringe Größe. Das Problem ist fehlende fachliche Eigenständigkeit.

Technische Teilbarkeit ist nicht dasselbe wie fachliche Unabhängigkeit.

Wenn Remotes zu groß werden

Das Gegenstück zur Fragmentierung ist ein Remote, das nahezu die gesamte Anwendung umfasst:

Verwaltungs-Remote
├── Patienten
├── Kalender
├── Abrechnung
├── Dokumente
├── Benutzer
└── Einstellungen

Formal kann dieses System weiterhin separat gebaut und deployt werden. Gegenüber dem Host besitzt es vielleicht sogar eine klare technische Grenze.

Innerhalb des Remotes wurden jedoch mehrere Fachbereiche zusammengefasst, die sich unabhängig voneinander verändern könnten. Sie verwenden unterschiedliche Fachsprachen, greifen auf verschiedene Backend-Verträge zu und werden möglicherweise von verschiedenen Teams verantwortet.

Dadurch entstehen erneut breite Builds und Tests. Releases betreffen mehrere Bereiche. Refactorings erhalten einen großen Wirkungsradius. Teams arbeiten im selben Codebereich und müssen Änderungen untereinander koordinieren.

Die separate Deployment-Pipeline ändert daran wenig. Das Remote ist zu einem Frontend-Monolithen innerhalb des Hosts geworden.

Ein Remote ist nicht deshalb angemessen geschnitten, weil es separat deployt werden kann.

Der Fehler liegt auch hier nicht primär in seiner Dateigröße. Entscheidend ist, dass mehrere unabhängig veränderliche Fachbereiche unter einer gemeinsamen Verantwortung gebündelt wurden.

Ein großes Remote ist deshalb nicht automatisch falsch. Ein fachlich tiefer Bereich kann umfangreich sein. Verdächtig wird die Grenze dort, wo unterschiedliche Verantwortliche, Fachsprachen, Releasegeschwindigkeiten oder Sicherheitsanforderungen innerhalb desselben Remotes aufeinandertreffen.

Eine Route ist keine fachliche Grenze

Routen sind ein Navigationskonzept. Sie machen Inhalte adressierbar und bestimmen, welche Oberfläche bei einer URL angezeigt wird.

Daraus folgt jedoch keine fachliche Verantwortung.

Ein Microfrontend kann mehrere Routen besitzen. Eine Route kann nur einen Schritt innerhalb eines größeren fachlichen Ablaufs darstellen. Eine Seite kann mehrere eigenständige Bereiche integrieren. Auch ein Dialog, eine Karte oder ein Widget ist nicht automatisch eine sinnvolle Architekturgrenze.

Die URL-Struktur beschreibt Navigation. Sie beschreibt nicht automatisch fachliche Verantwortung.

Ebenso wenig bildet ein gemeinsames Layout einen fachlichen Zusammenhang. Header, Navigation und Inhaltsbereich können visuell eine Einheit darstellen, obwohl sie unterschiedliche Lebenszyklen und Verantwortlichkeiten besitzen.

Umgekehrt kann ein zusammenhängender Bereich über Listen, Detailseiten, Assistenten und Dialoge verteilt sein. Ihn entlang dieser sichtbaren Elemente zu zerlegen würde seine Fachlichkeit nicht klarer machen.

Eine Route ist kein Bounded Context. Eine UI-Komponente ist keine organisatorische Einheit.

Ein Remote pro View ist eine Heuristik

Die Regel „ein Remote pro View“ kann trotzdem hilfreich sein. Sie begrenzt die Zahl der Laufzeitintegrationen innerhalb eines fachlichen Ablaufs und hält Zustandsgrenzen verständlich.

Eine View, die weitgehend von einem Remote verantwortet wird, lässt sich häufig einfacher lokal entwickeln und testen. Ladezustände, Fehlerfälle und Benutzerinteraktionen bleiben innerhalb eines Bereichs. Der Host muss weniger Teile koordinieren.

Damit ist die Regel eine brauchbare Warnleuchte gegen übermäßige Fragmentierung.

Sie ist jedoch keine Definition eines Microfrontends.

Eine Seite kann durchaus mehrere unabhängige Bereiche integrieren. Dazu gehören etwa Navigation und andere Plattformfunktionen, ein eigenständiges Reporting-Widget oder eine Zusatzfunktion mit eigener Lebensdauer.

Problematisch wird eine View mit vielen Remotes vor allem dann, wenn alle Teile gemeinsam einen einzigen fachlichen Ablauf bilden. Warnsignale sind ein ständiger Austausch von Zustand, ausschließlich gemeinsame Tests, synchrone Veröffentlichungen und fehlende Verantwortung für das Gesamterlebnis.

Ein Remote pro View ist eine brauchbare Warnleuchte gegen Fragmentierung, aber keine universelle Architekturregel.

Größe ist auch eine organisatorische Frage

Ein fachlich plausibler Bereich kann trotzdem zu groß für ein Team sein.

Die Domäne kann sehr tief sein, umfangreiches Spezialwissen erfordern oder eine hohe Änderungsfrequenz besitzen. Mehrere parallele Initiativen, technische Betriebsverantwortung und komplexe Fachregeln können die kognitive Belastung erhöhen.

Damit entsteht eine wichtige Unterscheidung:

Eine Grenze kann fachlich richtig und organisatorisch trotzdem zu breit sein.

Die Lösung besteht dann nicht automatisch darin, Komponenten oder Bildschirmbereiche auf mehrere Teams zu verteilen. Zunächst ist zu prüfen, ob innerhalb des Bereichs tatsächlich weitere eigenständige Veränderungsräume existieren.

Vielleicht besitzt die Domäne unterschiedliche Teilbereiche mit eigener Sprache, eigenen Regeln und eigener Releasegeschwindigkeit. Dann kann eine weitere Trennung sinnvoll sein.

Vielleicht greifen die Teile jedoch so eng ineinander, dass eine technische Aufteilung nur zusätzliche Kommunikation erzeugen würde. In diesem Fall liegt das Problem möglicherweise eher in Teamgröße, Priorisierung, Wissensverteilung oder technischer Komplexität als in der fachlichen Grenze.

Mehrere Teams innerhalb eines Remotes sind ein Warnsignal. Sie sind noch kein Beweis für einen falschen Schnitt.

Fragen für eine plausible Grenze

Eine feste Größenformel gibt es nicht. Konkrete Fragen helfen jedoch dabei, eine Grenze zu prüfen:

• Verwenden die Funktionen dieselbe fachliche Sprache?
• Ändern sie sich typischerweise aus denselben Gründen?
• Können sie von einem Team sinnvoll verstanden und verantwortet werden?
• Besitzen sie einen gemeinsamen, beherrschbaren Backend-Vertrag?
• Werden sie normalerweise gemeinsam oder unabhängig veröffentlicht?
• Muss eine Änderung regelmäßig mit anderen Remotes abgestimmt werden?
• Würde eine weitere Trennung echte Autonomie schaffen oder nur Kommunikation hinzufügen?
• Enthält das Remote Bereiche mit unterschiedlichen Verantwortlichen?
• Besitzen einzelne Teile deutlich verschiedene Releasegeschwindigkeiten?
• Kann der Bereich lokal entwickelt und getestet werden, ohne große Teile des Gesamtsystems zu starten?
• Ist die Grenze fachlich verständlich, ohne auf das Architekturdiagramm zu zeigen?

Diese Fragen ergeben keinen Score und keine mathematisch richtige Größe. Sie machen lediglich sichtbar, ob technische Grenzen und tatsächliche Veränderungsräume zusammenpassen.

Die wirtschaftlich sinnvolle Grenze ist selten die technisch kleinste

Jede zusätzliche Remote-Grenze erzeugt Kosten.

Zu kleine Remotes benötigen zusätzliche Pipelines, Integrationsmechanismen, Verträge, Tests und Observability. Fehler können über mehrere Laufzeitgrenzen verteilt sein. Lokale Entwicklung und Fehlersuche werden aufwendiger. Teams müssen sich koordinieren, obwohl die Architektur eigentlich Autonomie schaffen sollte.

Zu große Remotes verursachen andere Kosten. Builds und Tests werden breiter. Releasezyklen verlängern sich. Refactorings betreffen mehr Funktionen. Mehrere Teams müssen Änderungen in demselben Bereich abstimmen. Verantwortung wird diffuser, Entscheidungen werden langsamer.

Die wirtschaftlich sinnvolle Grenze liegt deshalb nicht bei der kleinsten technisch möglichen Einheit.

Sie liegt dort, wo zusätzliche Trennung mehr unabhängige Veränderbarkeit schafft, als sie Integrations- und Betriebsaufwand erzeugt.

Grenzen werden durch Änderungen überprüft

Auch eine sorgfältig gewählte Grenze kann sich später als falsch erweisen. Produkte verändern sich, Verantwortlichkeiten verschieben sich und zuvor eng gekoppelte Funktionen entwickeln unterschiedliche Lebenszyklen.

Grenzziehung bleibt deshalb eine Architekturentscheidung unter Unsicherheit.

Häufige gemeinsame Änderungen über mehrere Remotes hinweg können darauf hinweisen, dass ein zusammenhängender Bereich zu stark fragmentiert wurde. Regelmäßige Konflikte mehrerer Teams innerhalb desselben Remotes können dagegen auf eine zu breite Verantwortung hindeuten.

Diese Signale sind keine automatischen Beweise. Gemeinsame Deployments allein machen eine Grenze nicht falsch. Ein großes Remote allein ist noch kein Frontend-Monolith. Entscheidend ist die beobachtete Änderungskopplung.

Gute Grenzen entstehen nicht durch einmalige Vermessung, sondern werden durch reale Änderungen überprüft.

Die richtige Größe eines Microfrontends lässt sich nicht zählen. Sie zeigt sich daran, ob ein Team innerhalb dieser Grenze Änderungen vornehmen kann, ohne regelmäßig das restliche Produkt koordinieren zu müssen.

So klein wie möglich ist keine Architekturregel. So klar abgegrenzt wie nötig schon.