Grundlegende Konzepte

Die Micro-Frontend-Architektur ist stark von drei früheren Architekturkonzepten inspiriert:

• Domänengesteuertes Design ist das mentale Modell zur Strukturierung komplexer Anwendungen in kohärente Bereiche.

• Verteilte Systeme sind ein Ansatz zur Erstellung von Anwendungen als lose gekoppelte Subsysteme, die unabhängig voneinander entwickelt werden und auf ihrer eigenen dedizierten Infrastruktur ausgeführt werden.

• Cloud Computing ist ein Ansatz für den Betrieb von IT-Infrastrukturen als Dienste mit einem pay-as-you-go Modell.

Domänengesteuertes Design

Domain-Driven Design (DDD) ist ein von Eric Evans entwickeltes Paradigma. In seinem 2003 erschienenen Buch Domain-Driven Design: Tackling Complexity in the Heart of Software postuliert Evans, dass sich die Softwareentwicklung eher an geschäftlichen als an technischen Belangen orientieren sollte. Evans schlägt vor, dass IT-Projekte zunächst eine allgegenwärtige Sprache entwickeln, die Fach- und Fachexperten hilft, ein gemeinsames Verständnis zu finden. Auf der Grundlage dieser Sprache können sie ein für alle Seiten verständliches Modell der Geschäftsrealität formulieren.

So offensichtlich dieser Ansatz auch sein mag, viele Softwareprojekte leiden unter einer Diskrepanz zwischen Geschäft und IT. Diese Unterbrechungen führen häufig zu erheblichen Missverständnissen, die zu Budgetüberschreitungen, Qualitätseinbußen oder zum Scheitern von Projekten führen.

Evans führt mehrere weitere wichtige Begriffe ein, von denen einer den begrenzten Kontext ist. Ein begrenzter Kontext ist ein in sich geschlossenes Segment einer großen IT-Anwendung, das die Lösung oder Implementierung für genau ein Geschäftsproblem enthält. Eine große Anwendung besteht aus mehreren begrenzten Kontexten, die durch Integrationsmuster lose miteinander verknüpft sind. Diese begrenzten Kontexte können sogar ihre eigenen Dialekte der allgegenwärtigen Sprache haben. Beispielsweise könnte ein Benutzer im Zahlungskontext einer Anwendung andere Aspekte haben als ein Benutzer im Lieferkontext, weil der Begriff Versand bei der Zahlung irrelevant wäre.

Evans definiert nicht, wie klein oder groß ein begrenzter Kontext sein sollte. Die Größe wird durch das Softwareprojekt bestimmt und kann sich im Laufe der Zeit ändern. Gute Indikatoren für die Grenzen eines Kontextes sind der Grad der Kohäsion zwischen den Entitäten (Domänenobjekten) und der Geschäftslogik.

Im Kontext von Mikro-Frontends lässt sich domänengesteuertes Design am Beispiel einer komplexen Webseite wie einer Flugbuchungsseite veranschaulichen.

Die Hauptbausteine auf dieser Seite sind ein Suchformular, ein Filterfenster und die Ergebnisliste. Um die Grenzen zu identifizieren, müssen Sie unabhängige funktionale Kontexte identifizieren. Berücksichtigen Sie außerdem nicht funktionale Aspekte wie Wiederverwendbarkeit, Leistung und Sicherheit. Der wichtigste Indikator dafür, dass „Dinge zusammengehören“, sind ihre Kommunikationsmuster. Wenn einige Elemente in einer Architektur häufig kommunizieren und komplexe Informationen austauschen müssen, haben sie wahrscheinlich denselben begrenzten Kontext.

Einzelne Benutzeroberflächenelemente wie Schaltflächen sind keine begrenzten Kontexte, da sie nicht funktionell unabhängig sind. Außerdem eignet sich die gesamte Seite nicht gut für einen begrenzten Kontext, da sie in kleinere unabhängige Kontexte unterteilt werden kann. Ein vernünftiger Ansatz besteht darin, das Suchformular als einen begrenzten Kontext und die Ergebnisliste als zweiten begrenzten Kontext zu behandeln. Jeder dieser beiden begrenzten Kontexte kann nun als separates Mikrofrontend implementiert werden.

Verteilte Systeme

Um die Wartung zu vereinfachen und die Fähigkeit zur Weiterentwicklung zu unterstützen, sind die meisten nicht trivialen IT-Lösungen modular aufgebaut. Modular bedeutet in diesem Fall, dass IT-Systeme aus identifizierbaren Bausteinen bestehen, die durch Schnittstellen voneinander getrennt sind, um eine Trennung der einzelnen Bereiche zu erreichen.

Verteilte Systeme sollten nicht nur modular sein, sondern auch eigenständige, unabhängige Systeme sein. In einem rein modularen System ist jedes Modul idealerweise gekapselt und stellt seine Funktionen über Schnittstellen zur Verfügung, aber es kann nicht unabhängig voneinander eingesetzt werden oder auch nur eigenständig funktionsfähig sein. Außerdem folgen Module im Allgemeinen demselben Lebenszyklus wie andere Module, die Teil desselben Systems sind. Die Bausteine eines verteilten Systems haben dagegen jeweils ihre eigenen Lebenszyklen. Unter Anwendung des domänengesteuerten Entwurfsparadigmas adressiert jeder Baustein eine Geschäftsdomäne oder Subdomäne und lebt in seinem eigenen begrenzten Kontext.

Wenn verteilte Systeme während der Erstellungszeit interagieren, besteht ein gängiger Ansatz darin, Mechanismen zur schnellen Identifizierung von Problemen zu entwickeln. Sie könnten beispielsweise typisierte Sprachen verwenden und viel in Komponententests investieren. Mehrere Teams können bei der Entwicklung und Wartung von Modulen zusammenarbeiten, die häufig als Bibliotheken verteilt werden, damit Systeme sie mit Tools wie npm, Apache Maven und pip nutzen können. NuGet

Während der Laufzeit gehören interagierende verteilte Systeme in der Regel einzelnen Teams. Die Nutzung von Abhängigkeiten führt aufgrund von Fehlerbehandlung, Leistungsausgleich und Sicherheit zu betrieblicher Komplexität. Investitionen in Integrationstests und Beobachtbarkeit sind für die Reduzierung von Risiken von grundlegender Bedeutung.

Die beliebtesten Beispiele für verteilte Systeme sind heute Microservices. In Microservice-Architekturen sind Backend-Services domänengesteuert (und nicht von technischen Belangen wie Benutzeroberfläche oder Authentifizierung abhängig) und gehören autonomen Teams. Mikro-Frontends basieren auf denselben Prinzipien und erweitern den Lösungsumfang auf das Frontend.

Cloud-Computing

Cloud Computing ist eine Möglichkeit, IT-Infrastruktur als Service mit einem pay-as-you-go Modell zu erwerben, anstatt eigene Rechenzentren aufzubauen und Hardware zu kaufen, um sie vor Ort zu betreiben. Cloud Computing bietet mehrere Vorteile:

• Ihr Unternehmen gewinnt erheblich an geschäftlicher Flexibilität, da es in der Lage ist, mit neuen Technologien zu experimentieren, ohne im Voraus große, langfristige finanzielle Verpflichtungen eingehen zu müssen.

• Durch die Nutzung eines Cloud-Anbieters wie AWS kann Ihr Unternehmen auf ein breites Portfolio wartungsarmer und hochintegrierbarer Dienste (wie API-Gateways, Datenbanken, Container-Orchestrierung und Cloud-Funktionen) zugreifen. Durch den Zugriff auf diese Dienste können sich Ihre Mitarbeiter auf Aufgaben konzentrieren, die Ihr Unternehmen von der Konkurrenz abheben.

• Wenn Ihr Unternehmen bereit ist, eine Lösung weltweit einzuführen, können Sie die Lösung in der Cloud-Infrastruktur auf der ganzen Welt einsetzen.

Cloud Computing unterstützt Mikro-Frontends, indem es eine hochgradig verwaltete Infrastruktur bereitstellt. Dies erleichtert funktionsübergreifenden Teams die end-to-end Eigenverantwortung. Das Team sollte zwar über fundierte Betriebskenntnisse verfügen, aber die manuellen Aufgaben der Infrastrukturbereitstellung, Betriebssystemaktualisierungen und Netzwerke würden ablenkend sein.

Da Mikro-Frontends in begrenzten Kontexten existieren, können Teams den am besten geeigneten Dienst für ihren Betrieb auswählen. Teams können beispielsweise zwischen Cloud-Funktionen und Containern für die Datenverarbeitung wählen, und sie können zwischen verschiedenen Varianten von SQL- und NoSQL-Datenbanken oder In-Memory-Caches wählen. Teams können ihre Mikro-Frontends sogar auf einem hochintegrierten Toolkit aufbauen AWS Amplify, wie z. B., das vorkonfigurierte Bausteine für eine serverlose Infrastruktur enthält.