Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Identifizieren Sie die Grenzen des Mikro-Frontends
Um die Autonomie des Teams zu verbessern, können die von einer Anwendung bereitgestellten Geschäftsfunktionen in mehrere Mikrofrontends mit minimalen Abhängigkeiten voneinander aufgeteilt werden.
Gemäß der zuvor erörterten DDD-Methodik können Teams eine Anwendungsdomäne in Geschäftssubdomänen und begrenzte Kontexte unterteilen. Autonome Teams können dann die Funktionalität ihrer begrenzten Kontexte selbst in die Hand nehmen und diese Kontexte als Mikro-Frontends bereitstellen. Weitere Informationen zur Trennung von Problemen finden Sie im Serverless
Ein klar definierter, begrenzter Kontext sollte funktionale Überschneidungen und den Bedarf an kontextübergreifender Laufzeitkommunikation minimieren. Die erforderliche Kommunikation kann mit ereignisgesteuerten Methoden implementiert werden. Dies unterscheidet sich nicht von einer ereignisgesteuerten Architektur für die Entwicklung von Microservices.
Eine gut konzipierte Anwendung sollte auch die Bereitstellung zukünftiger Erweiterungen durch neue Teams unterstützen, um den Kunden ein einheitliches Erlebnis zu bieten.
Wie unterteilt man eine monolithische Anwendung in Mikro-Frontends
Der Abschnitt Überblick enthielt ein Beispiel für die Identifizierung unabhängiger funktionaler Kontexte auf einer Webseite. Es ergeben sich mehrere Muster für die Aufteilung der Funktionen auf der Benutzeroberfläche.
Wenn die Geschäftsdomänen beispielsweise Phasen einer Benutzerreise bilden, kann eine vertikale Aufteilung im Frontend angewendet werden, bei der eine Sammlung von Ansichten innerhalb der Benutzerreise als Mikro-Frontends bereitgestellt wird. Das folgende Diagramm zeigt eine vertikale Aufteilung, bei der die Schritte „Katalog“, „Checkout“ und „Rechnung“ von separaten Teams als separate Mikrofrontends bereitgestellt werden.
Für einige Anwendungen reicht die vertikale Aufteilung allein möglicherweise nicht aus. Beispielsweise müssen einige Funktionen möglicherweise in vielen Ansichten bereitgestellt werden. Für diese Anwendungen können Sie eine gemischte Aufteilung anwenden. Das folgende Diagramm zeigt eine gemischte Split-Lösung, bei der Mikro-Frontends für Station Finder und Route Explorer beide die Kartenansichtsfunktion verwenden.
Anwendungen vom Typ Portal oder Dashboard fassen in der Regel Frontend-Funktionen in einer einzigen Ansicht zusammen. Bei diesen Arten von Anwendungen kann jedes Widget als Mikro-Frontend bereitgestellt werden, und die Hosting-Anwendung definiert die Einschränkungen und Schnittstellen, die die Mikro-Frontends implementieren sollen.
Dieser Ansatz bietet Mikro-Frontends einen Mechanismus, mit dem Probleme wie die Größe von Viewports, Authentifizierungsanbieter, Konfigurationseinstellungen und Metadaten berücksichtigt werden können. Diese Arten von Anwendungen sind im Hinblick auf ihre Erweiterbarkeit optimiert. Neue Funktionen können von neuen Teams entwickelt werden, um die Dashboard-Funktionen zu skalieren.
Das folgende Diagramm zeigt eine Dashboard-Anwendung, die von drei einzelnen Teams entwickelt wurde, die Teil von Team Dashboard sind.
In dem Diagramm stellt die future Ansicht neue Funktionen dar, die von neuen Teams entwickelt wurden, um das Team-Dashboard und die Dashboard-Funktionen zu skalieren.
Portal- und Dashboard-Anwendungen stellen in der Regel Funktionen zusammen, indem sie eine gemischte Aufteilung der Benutzeroberfläche verwenden. Die Mikrofrontends sind mit genau definierten Einstellungen, einschließlich Positions- und Größenbeschränkungen, konfigurierbar.
