1. Es gibt eine Obergrenze für die Größe von Produktteams, wird diese überschritten, wird Arbeit ineffizienter. Die Idee für heutige Anwendungen ist daher kleine untereinander vernetzte Komponenten einzusetzen. Dabei steht zu beachten:

   ◦ Die Kriterien, nach denen geschnitten wird (Domänen und Bounded Context). Die Aufteilung sollte anhand von fachlichen Kriterien im Unternehmen erfolgen – Domänendenken.

   ◦ Die einzelnen Teams sollten sich als Produkt- und nicht als Projektteams fühlen.

   ◦ Die Teams sollten interdisziplinär besetzt und möglichst autonom sein.

2. Bei MS basierten Architekturen stellt sich für die Integration von UI die Grundsatzfrage – sollen headless oder headfull MS verwendet werden. Dabei kann zwischen unterschiedlichen Abhängigkeiten gewählt werden:

   ◦ Frontend Monoliths: Es entstehen Abhängigkeiten zwischen den Teams. Die Teams müssen für Releases auf andere Teams warten und das UI-Team stellt einen Flaschenhals für die Wünsche der anderen Teams dar.

   ◦ Micro Frontends: Teams müssen sich auf die verwendete Technologie einigen (mit Ausnahmen z. B. durch runtime module loading) können dafür aber unabhängig voneinander arbeiten.

   ◦ Als Zwischenstufe: Little Frontends, bei denen sich zusammenhängende MS eine UI-Komponente teilen und für die, die entsprechenden Teams gemeinsam verantwortlich sind.

3. Zur Integration von MF gibt es eine Vielzahl von Ansätzen und Technologien, mit ganz unterschiedlichen Vor- und Nachteilen. Die jeweils passende muss für jeden Einzelfall gewählt werden.

4. Bei der Integration der MF untereinander kann die Kommunikation im Frontend (Client), im Backend oder gemischt erfolgen. Die Integration im Frontend ist dabei weniger aufwendig und verlagert Last auf den Client, die Integration im Backend dagegen ist häufig passgenauer und längere automatisierte Prozesse gehören eher ins Backend.

5. Grundsätzlich sollte bei allen Entscheidungen immer der Nutzen für das Produkt/Unternehmen – der Business Value – zur Grundlage der Entscheidung gemacht werden. Er sollte dabei als wichtigstes Kriterium in Entscheidungen einfließen.

6. Wiederverwendbarkeit von Komponenten ist nur dort möglich/sollte nur dort angestrebt werden, wo:

   ◦ Die infrage kommenden Komponenten Teil des gleichen Bounded Context sind.

   ◦ Gleiche Benutzergruppen mit gleichen Anforderungen angesprochen werden.

   ◦ Die Mehrkosten nicht zu hoch sind (gerade für komplexe wiederverwendbare Komponenten besteht häufig kein Bedarf).

7. Wichtig für MS/Microfrontend Architekturen ist die Durchführung von Ende zu Ende Tests. Dabei stellt die Durchführung dieser Tests ein Problem dar, welches noch nicht zufriedenstellenden gelöst ist. Ende zu Ende Tests werden deshalb oft vernachlässigt.

8. Komponentenbildung sollte immer genau durchdacht werden. Es sollte keine unnötige Aufteilung in Komponenten stattfinden.

(Rechtsklick -> Ziel speichern unter)

Kernaussagen (PDF)