Nachdem ich euch neulich Islands Architecture vorgestellt habe, möchte ich jetzt einen Schritt weitergehen und schauen, wie sich das Pattern für die Entwicklung von Businessanwendungen eignet. Und wie sieht es eigentlich mit Microfrontends aus?

Wie so oft im Jahr 2024 habe ich bei der Recherche erst einmal ChatGPT gefragt und gelernt, dass Islands Architecture und Microfrontends nichts miteinander zu tun haben. Es sind laut ChatGPT vollkommen unterschiedliche Konzepte mit unterschiedlichen Einsatzszenarien. Das hat mich lange verwirrt, weil mir in erster Linie die Ähnlichkeiten aufgefallen waren. Erst nach einer ganzen Weile ist der Groschen gefallen: Was ich suche, ist eine Möglichkeit, das Frontend zu modularisieren und stärker zu entkoppeln, als es mit der klassischen Komponentenbildung möglich ist. Microfrontends gehen noch weiter und erfordern eigene Server. Das passt nicht so recht zur Idee von Islands Architecture, wo der Fokus auf dem schnellen Ausliefern von HTML liegt. Das hindert einige Entwicklerinnen und Entwickler aber nicht daran, Microfrontends und Islands Architecture zu kombinieren.

Bevor wir loslegen, will ich euch kurz mit den Begriffen „Microservice“ und „Microfrontend“ vertraut machen und dabei meine Beispielanwendung vorstellen. Ich mache es kurz – als langjährige Leserinnen und Leser des Java Magazins ist es für euch wahrscheinlich eine Wiederholung, und die Anwendung habt ihr auch schon im letzten Artikel gesehen.

Teile und herrsche

Moderne Anwendungen sind groß und unübersichtlich geworden, sodass es Sinn ergibt, sie in kleinere Teile aufzuspalten. Ein populärer Ansatz ist es, sich dabei von der Fachlichkeit leiten zu lassen. Ihr teilt die Anwendungen also in unterschiedliche fachliche Domänen auf, die wenig Überschneidungen haben.

Stellt euch beispielsweise vor, ihr arbeitet bei einer Bank und wollt die Kredite der Kunden verwalten. Da gibt es zunächst einmal den Kredit selbst: seine Höhe, die Höhe der Zinsen, die Laufzeit und so weiter. Ihr braucht aber auch die beteiligten Personen: Wer hat den Kredit aufgenommen und wer bürgt dafür? Die dritte fachliche Domäne sind die Sicherheiten. Jede dieser drei Domänen ist verblüffend komplex. Ihr denkt vermutlich zunächst an euren Ratenkredit oder an eure Hypothek, mit der ihr euer Haus bezahlt. Das sind zwei unterschiedliche Kontotypen mit vielen Gemeinsamkeiten, aber auch vielen Unterschieden im Detail. Ein dritter Typ, den ihr – hoffentlich – nur selten braucht, ist der Überziehungskredit auf eurem Girokonto.

Ähnlich sieht es mit den Sicherheiten aus: Ihr könnt euer Haus als Sicherheit bieten, aber auch Aktien, euer Auto oder sogar eine Bürgschaft. Für die Genehmigung des Kredits ist nur relevant, wie viel die Sicherheit wert ist. Es gibt also nur eine sehr schmale Schnittstelle zwischen Kredit und Sicherheit. Innerhalb der Domäne sieht es anders aus: Der Wert eines Fahrzeugs wird anders ermittelt als der Wert eine Immobilie oder eines Hauses.

Microservices

Für Backend-Entwickler und -Entwicklerinnen ist das ein alter Hut – ihr teilt eure Anwendung in drei getrennte Projekte auf. Diese drei Projekte werden von drei getrennten Teams umgesetzt, jedes der Projekte liefert eine eigenständige Serveranwendung, und fertig ist die Microservices-Architektur. Das Schöne im Backend ist, dass das funktioniert. Die drei Teilprojekte brauchen nicht viel voneinander zu wissen. Mein Beispiel habe ich so konstruiert, dass sie überhaupt keine gemeinsame Schnittstelle haben. Die einzige Ausnahme ist die Genehmigung des Kredits. Das wiederum ist ein so komplexes Thema, dass es sich lohnt, hieraus einen vierten Microservice zu bauen, der die drei anderen Microservices via REST API aufruft.

Microfrontends

Schauen wir uns das Frontend unserer Anwendung in Abbildung 1 an. Von unserer klaren Trennung ist nichts mehr zu sehen. Stattdessen haben wir ein Durcheinander verschiedener Domänen auf der Maske. Ihr könnt als Architektin oder Architekt versuchen, dagegen anzukämpfen. Empfehlenswert ist das nicht: Eure Kunden haben mit ganz anderen Herausforderungen zu kämpfen als die IT. Ein klarer Domänenschnitt hilft ihnen nicht. Im Gegenteil, sie wollen meistens einen 360°-Überblick quer über alle Dom...