Welches Problem lösen Microfrontends eigentlich?

Die verbreitetste Begründung für Microfrontends klingt zunächst plausibel:

Unsere Frontendanwendung ist groß, deshalb brauchen wir Microfrontends.

Nur beschreibt „groß“ noch kein Architekturproblem.

Eine große Anwendung kann fachlich sauber modularisiert sein. Sie kann von einem Team verstanden, schnell gebaut, zuverlässig getestet und wirtschaftlich sinnvoll als Einheit ausgeliefert werden. Umgekehrt kann eine Anwendung aus einem Host und zehn Remotes bestehen und trotzdem bei jeder Änderung einen gemeinsamen Releasezug, mehrere Freigaben und die Abstimmung mit drei anderen Teams benötigen.

Die Zahl der Dateien ist deshalb selten die entscheidende Größe. Auch die Größe eines Bundles oder die Dauer eines vollständigen Builds sind zunächst nur Symptome. Die wichtigere Frage lautet:

Welche Änderungen sollen Teams durchführen können, ohne dafür das gesamte Produkt und mehrere andere Teams koordinieren zu müssen?

Microfrontends adressieren nicht primär zu viel Frontend-Code. Ihr strategischer Wert entsteht dort, wo organisatorische und technische Abhängigkeiten so geschnitten werden können, dass Teams fachliche Bereiche eigenständiger verstehen, verändern, testen, veröffentlichen und betreiben können.

Das ist eine Möglichkeit, keine Garantie.

Eine technische Aufteilung in Host und Remotes erzeugt weder fachliche Ownership noch unabhängige Teams. Sie erzeugt zunächst nur mehrere technische Einheiten. Ob daraus echte Autonomie oder lediglich verteilte Kopplung entsteht, entscheidet die Architektur.

Zwei Dimensionen der Unabhängigkeit

Wenn über Microfrontends gesprochen wird, werden organisatorische und technische Unabhängigkeit häufig vermischt. Beide hängen zusammen, sind aber nicht dasselbe.

Aus organisatorischer Sicht können Microfrontends einen Rahmen schaffen, in dem ein Team einen fachlichen Bereich verantwortet. Dieses Team besitzt eigene Prioritäten, entscheidet über Releases und trägt Verantwortung für Qualität und Betrieb. Unterschiedliche Produktbereiche können sich mit unterschiedlichen Geschwindigkeiten entwickeln, ohne dass jede Änderung einen gemeinsamen Takt benötigt.

Dabei geht es um unabhängigere Teams, nicht um isolierte Teams.

Gemeinsame Standards, Plattformentscheidungen und fachliche Abstimmung bleiben notwendig. Autonomie bedeutet nicht, dass niemand mehr miteinander sprechen muss. Sie bedeutet, dass nicht jede lokale Änderung eine organisationsweite Verhandlung auslöst.

Technische Unabhängigkeit beschreibt dagegen konkrete Eigenschaften eines Systems:

• ein eigener Build
• fokussierte Tests
• ein separates Deployment
• ein eigener Datenzugriff
• lokaler UI- und Anwendungszustand
• explizite Integrationsverträge
• ein gezielter Rollback
• begrenzte Veränderungs- und Ausfallräume

Unter geeigneten Bedingungen kann ein Remote außerdem in unterschiedliche Hosts integriert werden. Auch das ist jedoch eine eigene Fähigkeit und nicht automatisch mit einem separaten Deployment verbunden.

Beide Dimensionen müssen zusammenpassen.

Ein Team ist nicht autonom, nur weil sein Remote eine eigene Pipeline besitzt. Wenn jede fachliche Änderung weiterhin Anpassungen an einer zentralen Library, eine neue Host-Version und ein synchron veröffentlichtes zweites Remote benötigt, wurde der Release technisch aufgeteilt, aber nicht unabhängig.

Umgekehrt bleibt organisatorische Ownership wirkungslos, wenn das verantwortliche Team technisch keinen Bereich besitzt, den es ohne Eingriffe anderer Teams verändern kann.

Organisatorische Autonomie ohne technische Entkopplung bleibt Absicht. Technische Entkopplung ohne Ownership bleibt Infrastruktur.

Ein eigenes Remote erzeugt noch keine fachliche Grenze

Ein Remote kann einen fachlichen Verantwortungsbereich sichtbar und technisch abgrenzbar machen. Das ist eine seiner interessantesten Eigenschaften.

Die Betonung liegt auf kann.

Ein fachlich schlecht geschnittenes Remote bleibt auch dann schlecht geschnitten, wenn es separat gebaut und ausgeliefert wird. Es kann dieselben Transportmodelle wie andere Remotes verwenden, auf einen globalen Store zugreifen, fachliche Regeln über gemeinsame Libraries verteilen oder von Events abhängen, deren Sender und Empfänger niemand vollständig überblickt.

Es besitzt dann zwar ein eigenes Repository, einen eigenen Build oder eine eigene Deployment-URL. Seine tatsächliche Veränderbarkeit bleibt jedoch von anderen Bereichen abhängig.

Ein typisches Missverständnis besteht darin, die technische Einheit mit dem fachlichen Verantwortungsbereich gleichzusetzen. Das Remote heißt vielleicht billing, verarbeitet aber nur einen kleinen Teil der Abrechnung. Wichtige Regeln liegen in der Shell, gemeinsam genutzte Formulare in einer Shared Library und die Freigabelogik in einem anderen Remote. Die Bezeichnung vermittelt Ownership, während die Architektur sie verhindert.

Eine solche Ownership lässt sich jedoch nicht durch Konfiguration erzeugen.

Der Wert eines Microfrontends liegt deshalb nicht darin, dass es klein ist. Er liegt darin, dass Änderungen innerhalb seiner Grenze möglichst wenig Zustimmung außerhalb dieser Grenze benötigen.

Begrenzte Veränderungsräume statt trivialer Anwendungen

Aus der Idee abgegrenzter Verantwortung entsteht schnell ein zweites Missverständnis: Ein Remote müsse klein, einfach und vollständig leicht verständlich sein.

Das ist nicht zwingend der Fall.

Der Kalender einer Arztpraxis klingt zunächst wie ein überschaubares Feature. Tatsächlich kann er eine ausgesprochen komplexe fachliche Domäne darstellen. Er muss Behandler, Räume und weitere Ressourcen koordinieren. Terminarten können unterschiedliche Dauern, Vorbereitungszeiten und Abhängigkeiten besitzen. Terminserien treffen auf Sperrzeiten, Parallelbehandlungen und Konfliktregeln. Ausfälle, Vertretungen, Berechtigungen und kurzfristige Verschiebungen verändern die Planung zusätzlich.

Diese Komplexität verschwindet nicht dadurch, dass der Kalender als eigenes Remote umgesetzt wird.

Das Kalenderteam muss seine Domäne möglicherweise sehr tief verstehen. Es muss wissen, wann zwei Termine tatsächlich parallel stattfinden dürfen, welche Ressource exklusiv benötigt wird und welche Änderung eine komplette Serie betrifft. Ein sauberer Schnitt verhindert nicht die fachliche Tiefe.

Er kann aber die Breite des Wissens begrenzen.

Das Team muss für eine Änderung am Belegungskonflikt nicht gleichzeitig die Regeln der Abrechnung, die Dokumentenverwaltung, die Patientenakte und die Systemadministration verstehen. Diese Bereiche bleiben Teil desselben Produkts, liegen aber außerhalb des unmittelbaren Veränderungsraums.

Microfrontends machen komplexe Fachlichkeit nicht einfach. Sie können aber verhindern, dass für jede Änderung die Komplexität des gesamten Produkts verstanden werden muss.

Die Größe eines Remotes lässt sich deshalb nicht sinnvoll nur in Codezeilen, Komponenten oder Bundle-Größe ausdrücken. Ein fachlich komplexer Bereich kann seine Berechtigung als eigenständige Einheit behalten, wenn seine Verantwortungsgrenze tragfähig ist.

Die entscheidende Frage lautet nicht: „Ist das Remote klein genug?“

Interessanter ist:

Welche Teile des Produkts muss ein Team verstehen und koordinieren, um diesen Bereich sicher zu verändern?

Fokussierte Builds und Tests

Neben dem organisatorischen Nutzen können Microfrontends auch konkrete technische Vorteile bieten.

Wenn ein Remote einen eigenen Veränderungsraum bildet, muss bei einer lokalen Änderung nicht zwangsläufig die gesamte Produktlandschaft gebaut und getestet werden. Betroffene Projekte können gezielt ermittelt, Builds fokussiert ausgeführt und Tests einem klaren Verantwortungsbereich zugeordnet werden.

In einem Monorepo können Affected-Strategien diese Eingrenzung zusätzlich unterstützen. Aber auch unabhängig von der konkreten Werkzeugwahl ist der grundsätzliche Vorteil derselbe: Die technische Feedbackschleife orientiert sich stärker an der tatsächlichen Änderung.

Diese Möglichkeit ist nicht exklusiv Microfrontends vorbehalten. Auch ein modularer Monolith kann Änderungen über einen sauberen Projektgraphen gezielt bauen und testen. Bei Microfrontends kann aus dieser technischen Eingrenzung zusätzlich eine unabhängige Auslieferung entstehen.

Das kann bedeuten:

• kürzere Buildzeiten
• kleinere Testmengen pro Änderung
• schnellere lokale Starts
• klarere Verantwortlichkeit für fehlschlagende Tests
• weniger unnötige Arbeit in der CI-Pipeline

Dabei darf aus einer kleineren Testfläche nicht der Schluss gezogen werden, dass Integrationstests überflüssig werden.

Weniger Tests pro Änderung bedeutet nicht weniger Arten von Tests.

Ein Remote benötigt weiterhin Tests für sein eigenes Verhalten. Zusätzlich können je nach Architektur Contract Tests, Host-Integration, Smoke Tests und Prüfungen kritischer Versionskombinationen notwendig sein.

Die Tests verschwinden nicht. Sie werden anders verteilt.

Das ist ein wichtiger Unterschied. Microfrontends reduzieren im günstigen Fall die Menge der unmittelbar betroffenen Tests. Gleichzeitig erzeugen sie neue Integrationsflächen, die ebenfalls abgesichert werden müssen. Ob die gesamte Teststrategie dadurch schneller und verlässlicher wird, hängt von den Grenzen und Verträgen des Systems ab.

Ein Deployment-Artefakt ist noch kein autonomes Deployment

Unabhängige Deployments gehören zu den stärksten Argumenten für Microfrontends.

Ein Team kann eine Änderung veröffentlichen, ohne andere Produktbereiche erneut auszuliefern. Ein Fehler kann gezielt zurückgerollt werden. Unterschiedliche Bereiche können unterschiedliche Releasefrequenzen besitzen. Ein stark veränderter Produktbereich muss nicht auf einen Bereich warten, der nur wenige Male im Jahr angepasst wird.

Das ist jedoch nur dann ein echter Vorteil, wenn das Deployment auch unabhängig aktiviert und betrieben werden kann.

Ein eigenes Artefakt allein reicht nicht aus.

Wenn Remote A nur mit einer bestimmten Host-Version funktioniert, gleichzeitig eine neue Shared Library benötigt und außerdem voraussetzt, dass Remote B in exakt derselben Version veröffentlicht wurde, dann existieren mehrere Deployment-Artefakte, aber weiterhin ein gemeinsamer Release.

Der technische Vorgang wurde verteilt. Die Veränderungsabhängigkeit blieb bestehen.

Autonome Deployments benötigen daher kontrollierte Verträge und eine bewusste Kompatibilitätsstrategie. Dazu gehören je nach Architektur Versionierung, Manifeste, kontrollierte Aktivierung und definierte Rollback-Szenarien. Die konkrete technische Umsetzung ist ein eigenes Thema. Für die grundlegende Einordnung genügt zunächst:

Ein Deployment ist nicht deshalb unabhängig, weil es eine eigene Pipeline besitzt. Es ist unabhängig, wenn es ohne synchronen Release anderer Bereiche sicher verändert werden kann.

Ein Remote in verschiedenen Hosts

Ein gut geschnittenes Remote kann unter bestimmten Bedingungen in mehrere Hosts integriert werden.

Nicht jedes Microfrontend muss in mehreren Hosts funktionieren. Wo diese Fähigkeit jedoch als Vorteil versprochen wird, muss sie durch explizite Plattformverträge und fehlende versteckte Shell-Abhängigkeiten tatsächlich ermöglicht werden.

Diese Möglichkeit ist besonders interessant, wenn ein fachlicher Bereich in unterschiedlichen Produkten, Mandantenlösungen oder Oberflächen benötigt wird. Sie setzt jedoch voraus, dass das Remote nicht heimlich Teil genau einer Shell bleibt.

Der Plattformkontext muss explizit übergeben werden. Das Remote sollte seine fachlichen Daten selbst laden oder zumindest über einen klaren Vertrag erhalten. Navigation und Authentifizierung müssen bewusst angebunden sein. Globale Styles und Zustände dürfen nicht zufällig vorausgesetzt werden.

Sobald ein Remote nur funktioniert, weil die Shell vor dem Start mehrere globale Variablen setzt, einen bestimmten Store initialisiert und eine Reihe undokumentierter Events sendet, ist seine technische Wiederverwendbarkeit eher theoretisch.

Drei Eigenschaften sollten deshalb getrennt betrachtet werden:

• unabhängig deploybar
• unabhängig betreibbar
• in verschiedene Hosts integrierbar

Ein Remote kann separat deployt werden und trotzdem ausschließlich in einer bestimmten Shell funktionieren. Es kann in mehreren Hosts eingebunden werden, aber für seinen Betrieb einen zentralen Backend-Prozess benötigen. Oder es kann technisch unabhängig betrieben werden, ohne jemals für eine Mehrfachintegration vorgesehen zu sein.

Diese Fähigkeiten ergänzen sich. Sie sind nicht identisch.

Klarere Grenzen können Refactoring erleichtern

Ein häufig unterschätztes Problem großer, stark gekoppelter Systeme ist nicht nur die objektive Komplexität. Es ist die Unsicherheit über die Folgen einer Änderung.

Ich weiß nicht, was davon noch alles abhängt.

Dieser Satz verhindert mehr notwendige Refactorings als fehlendes Wissen über Entwurfsmuster.

Wenn globale Zustände, gemeinsam genutzte Modelle und implizite Seiteneffekte das System durchziehen, wird selbst eine lokale Verbesserung riskant. Nicht weil die Änderung an sich besonders schwierig wäre, sondern weil ihr Blast Radius unbekannt ist.

Ein sauber abgegrenztes Remote kann diesen Radius besser sichtbar machen. Das Team kennt seine Verträge, besitzt gezielte Tests und kann eine Änderung separat veröffentlichen oder zurückrollen. Dadurch wird nicht jedes Refactoring automatisch sicher. Aber das wahrgenommene und tatsächliche Risiko kann sinken.

Mut zum Refactoring entsteht dabei nicht einfach durch weniger Code.

Ein kleines Remote kann durch globale Stores, Shared Libraries und unbekannte Event-Consumer stärker gekoppelt sein als ein großer, sauber modularisierter Bereich. Umgekehrt kann ein fachlich umfangreiches Remote gut veränderbar bleiben, wenn seine Grenzen bekannt und seine Abhängigkeiten explizit sind.

Mut zum Refactoring entsteht nicht durch wenig Code, sondern durch Vertrauen in die Grenzen des Systems.

Dieses Vertrauen muss technisch verdient werden. Ein eigener Ordner oder ein separates Repository reicht dafür nicht.

Weitere reale Möglichkeiten

Die bisher genannten Eigenschaften können weitere Einsatzmöglichkeiten unterstützen.

Ein Legacy-Frontend lässt sich beispielsweise schrittweise modernisieren, indem neue oder überarbeitete Bereiche kontrolliert neben dem bestehenden System entstehen. Produktbereiche können unterschiedliche Entwicklungsgeschwindigkeiten besitzen. Neue Fähigkeiten lassen sich in bestehende Hosts integrieren, ohne die gesamte Oberfläche neu aufzubauen.

Auch der Ausfallradius kann begrenzt werden. Ein optionaler Bereich muss nicht zwangsläufig das gesamte Produkt unbenutzbar machen. Voraussetzung ist allerdings, dass die Shell und die Integrationsarchitektur mit Ausfällen umgehen können. Ein dynamisch geladenes Remote allein besitzt noch kein belastbares Fallback.

Außerdem können Investitionen gezielter erfolgen. Ein strategisch wichtiger fachlicher Bereich kann eine eigene Roadmap, ein spezialisiertes Team und eine passende technische Architektur erhalten, ohne dass dieselben Entscheidungen unmittelbar für das gesamte Frontend gelten müssen.

Diese Möglichkeiten sind real. Sie entstehen aber nicht aus der bloßen Existenz mehrerer Deployments.

Was Microfrontends nicht automatisch liefern

Microfrontends eröffnen Möglichkeiten. Sie garantieren keine gute Architektur.

Das zeigt sich besonders bei Eigenschaften, die in Architekturdiagrammen schnell vorausgesetzt werden.

Einheitliche UI und UX

Ein gemeinsames Design-System kann visuelle Konsistenz unterstützen, indem es Farben, Typografie, Abstände und Komponenten vereinheitlicht. Es garantiert jedoch noch keine konsistenten Interaktionsmuster.

Zwei Remotes können dieselbe Button-Komponente verwenden und trotzdem Formulare unterschiedlich validieren, Navigation anders behandeln oder widersprüchliche Speicherkonzepte anbieten. Visuelle Einheitlichkeit und konsistente User Experience sind nicht dasselbe.

UI- und UX-Standards müssen als Plattformfähigkeit bewusst gestaltet werden.

Fehler und Notifications

Auch Fehlerbehandlung wird durch mehrere Remotes nicht automatisch besser.

Ein Remote zeigt einen Toast, ein zweites öffnet einen Dialog und ein drittes schreibt eine Meldung still in die Konsole. Selbst wenn alle drei technisch korrekt auf Fehler reagieren, entsteht für den Nutzer kein konsistentes Produkt.

Plattformstandards müssen festlegen, welche Fehler lokal behandelt werden, welche Informationen zentral sichtbar sein sollen und wie Notifications aussehen. Ein gemeinsamer Notification-Service kann dabei helfen. Er ersetzt aber nicht die fachliche Entscheidung, welche Meldung an welcher Stelle sinnvoll ist.

Events

Ein Event Bus stellt einen technischen Kommunikationskanal bereit. Er erzeugt keine gute fachliche Kommunikation.

Globale Events können Abhängigkeiten expliziter machen, wenn ihre Verträge klar definiert und ihre Zuständigkeiten nachvollziehbar sind. Sie können aber genauso gut einen unsichtbaren Ablaufgraphen erzeugen, in dem niemand mehr weiß, wer auf welches Ereignis reagiert.

Ein technischer Kanal ist noch keine Architektur.

Performance

Microfrontends verbessern nicht automatisch die Browserperformance.

Separate Remotes können zusätzliche Requests, doppelte Dependencies und mehrfach geladene Framework-Runtimes verursachen. Auch die Initialisierung mehrerer Anwendungen, redundante Styles oder unkoordinierte Datenzugriffe können die Laufzeitkosten erhöhen.

Unter geeigneten Bedingungen lassen sich Bereiche gezielt laden und Veränderungen besser isolieren. Ob das Ergebnis schneller oder langsamer ist, hängt jedoch von der konkreten Integration ab.

Security

Ein Remote unter derselben Origin ist keine isolierte Sandbox. Ein separates Repository oder Deployment erzeugt keine eigene Sicherheitsgrenze im Browser. Authentifizierung, Autorisierung und gemeinsam ausgeführter JavaScript-Code benötigen daher eine bewusste Sicherheitsarchitektur.

Backend-Unabhängigkeit

Mehrere Microfrontends können problemlos vor einem Backend-Monolithen betrieben werden.

Das kann eine sinnvolle Zwischenstufe oder sogar eine dauerhafte Lösung sein. Es bedeutet aber, dass Frontend-Autonomie und End-to-End-Autonomie auseinanderfallen können. Wenn jede fachliche Änderung weiterhin eine zentrale Backend-Freigabe benötigt, bleibt ein wesentlicher Teil der Abhängigkeit bestehen.

Das muss kein Fehler sein. In diesem Fall bleibt die erreichte Autonomie auf das Frontend begrenzt und sollte entsprechend ehrlich benannt werden.

Umgekehrt verlangt nicht jedes Microfrontend einen eigenen Microservice.

Die Backend-Struktur sollte aus fachlichen und betrieblichen Anforderungen entstehen, nicht aus einer symmetrischen Architekturzeichnung.

Gute fachliche Schnitte und gute Codequalität

Microfrontends erzeugen keine Bounded Contexts, nur weil mehrere Builds existieren. Sie verhindern keine God Components, keine unklaren Zuständigkeiten und keine imperativen Seiteneffektketten.

Schlechter Code kann in einem Remote genauso entstehen wie in einem Monolithen.

Der Unterschied besteht darin, dass seine Folgen durch Runtime-Integration, Deployment und teamübergreifende Verträge teurer werden können.

Microfrontends verzeihen schlechte Architektur nicht. Sie machen ihre Folgen sichtbarer und teurer.

Komplexität wird neu verteilt

Eine zentrale Erwartung an Microfrontends lautet, dass ein großes Frontend dadurch einfacher wird.

Lokal kann das stimmen.

Für eine konkrete Änderung sinkt möglicherweise der relevante fachliche Kontext. Weniger Teams sind unmittelbar betroffen. Der Build umfasst weniger Projekte. Tests können fokussierter ausgeführt werden. Der Blast Radius wird kleiner und besser einschätzbar.

Systemweit entsteht jedoch neue Komplexität:

• Integrationsverträge
• Versionierung
• Runtime-Integration
• Plattformstandards
• Observability
• Release-Governance
• Security-Grenzen
• Kompatibilitätsmanagement

Microfrontends vernichten Komplexität nicht. Sie verteilen sie neu.

Die entscheidende Frage ist deshalb nicht, ob das System nach der Aufteilung weniger komplex aussieht.

Entscheidend ist, ob die Komplexität an einer Stelle landet, an der Organisation und Technik sie besser beherrschen können.

Ein Plattformteam kann beispielsweise Runtime-Integration, gemeinsame Standards und Observability zentral lösen, während Produktteams ihre fachlichen Bereiche unabhängig verändern. Das kann wirtschaftlich sinnvoll sein, wenn viele Teams dieselben Plattformfähigkeiten benötigen und dadurch echte Koordinationskosten sinken.

Es kann aber auch das Gegenteil passieren. Eine kleine Organisation baut eine umfangreiche Plattform, obwohl nur ein Team an der Anwendung arbeitet. Die neue Integrationsarchitektur löst dann keinen realen Engpass, sondern erzeugt vor allem zusätzliche Betriebs- und Wartungsarbeit.

Die wirtschaftliche Leitfrage

Microfrontends sind besonders plausibel, wenn mehrere Teams regelmäßig parallel an derselben Produktlandschaft arbeiten und gemeinsame Releases zu einem tatsächlichen Engpass werden.

Sie können ebenfalls sinnvoll sein, wenn Produktbereiche unterschiedliche Veränderungsgeschwindigkeiten besitzen, fachliche Verantwortungsgrenzen tragfähig sind oder eine schrittweise Modernisierung notwendig ist. Auch die unabhängige Integration einzelner Bereiche in mehrere Hosts kann einen hohen Wert besitzen.

Weniger plausibel sind sie, wenn nur ein Team an der Anwendung arbeitet, ohnehin immer alles gemeinsam ausgeliefert wird oder die fachlichen Grenzen so unklar sind, dass fast jede Änderung mehrere Remotes betrifft.

In solchen Situationen kann ein modularer Monolith dieselben Ziele mit weniger Integrationsaufwand erreichen.

Das ist keine Vorstufe, die möglichst schnell überwunden werden muss. Ein gut strukturierter modularer Monolith kann für viele Produkte die wirtschaftlich bessere Architektur sein. Er kann fachliche Grenzen, klare Ownership und fokussierte Tests ermöglichen, ohne zusätzlich Runtime-Versionierung, verteilte Deployments und Kompatibilitätsmanagement einzuführen.

Die relevante wirtschaftliche Frage lautet daher nicht:

Können wir diese Anwendung in Microfrontends aufteilen?

Technisch lässt sich eine Anwendung fast immer irgendwie in mehrere Laufzeiteinheiten zerlegen.

Die wichtigere Frage lautet:

Ist der Wert unabhängiger Veränderbarkeit größer als der Preis verteilter Integration?

Dieser Preis umfasst nicht nur Infrastruktur. Er entsteht auch durch zusätzliche Verträge, Plattformarbeit, Betrieb, Fehlersuche und die Notwendigkeit, mehrere Laufzeiteinheiten als ein zusammenhängendes Produkt erscheinen zu lassen.

Eine belastbare Entscheidung beginnt deshalb beim Engpass.

Wenn Teams wegen gemeinsamer Releases, unklarer Ownership und produktweiter Testzyklen kaum unabhängig liefern können, können Microfrontends eine passende Antwort sein.

Wenn das eigentliche Problem jedoch schlechte Modularisierung, fehlende Tests oder unklare fachliche Verantwortlichkeiten sind, werden mehrere Remotes diese Probleme nicht lösen. Sie werden lediglich über mehrere Artefakte verteilt.

Unabhängige Veränderbarkeit als eigentlicher Maßstab

Der Wert eines Microfrontends liegt nicht darin, dass es kleiner ist.

Er liegt darin, dass ein Team einen fachlichen Bereich möglichst eigenständig verstehen, verändern, testen, veröffentlichen und betreiben kann.

Dabei darf der Bereich fachlich tief und technisch anspruchsvoll sein. Entscheidend ist, wie viele externe Abhängigkeiten für eine Änderung koordiniert werden müssen und wie klar die Verantwortung für das Ergebnis ist.

Microfrontends können fokussierte Builds, gezielte Tests, unterschiedliche Releasegeschwindigkeiten und schrittweise Modernisierung ermöglichen. Sie können fachliche Grenzen sichtbar machen und den Mut zu notwendigen Refactorings erhöhen.

Sie liefern all das nicht automatisch.

Ob aus Host und Remotes unabhängige Veränderungsräume oder ein verteilter Monolith entsteht, entscheidet nicht Module Federation.

Es entscheidet die Architektur.