Warum MS: Monolithen skalieren nicht gut bezieht sich auf unterschiedliche Aspekte: technisch (doppelte Last, zweite Instanz oder stärkere Maschinen erforderlich) entwicklung (sinnvolle obergröße für Produktteam(Entwicklungsteam), Monolith erfordert großes Team) Weiterentwicklung von Geschäftsideen (sehr schwierig neue dinge in System einzubauen, welches über Jahrzente gewachsen ist/techn. Wartbarkeit) heute Besser: kleine Komponenten, welche untereinander verdrahtet sind.

Wichtige Aspekte: Kriterien nach denen geschnitten wird(große dinge in kleine) Anhand von Unternehmensdingen(Domäne) - Domänendenken -> einzelne Teams fühlen sich als Produktteams, nicht als Projektteams Interdisziplinäre Teams, autonome Teams

MS sollen unabhängig voneinander ausgetauscht und aktualisiert werden können

in vielen kleinen Komponenten unterschiedliche Technologien

Grundsatzfrage bei MS: Headless odr headfull

| UI | vs. | UI| | UI| | UI| | A | | B | | C | | A | | B | | C |

4 Teams 3 Teams

autonome Teams; Seite "rechts" besser, weil weniger Klärungsbedarf/Abhängigkeiten Ein Team für gmeinsame UI, vs jeder MS eigene UI gemeinsame UI kann Flaschenhals für Entwicklung sein

Wählen zwischen unterschiedlichen Abhängigkeiten (Abhängigkeiten gibt es immer) Frontend Monoliths: Dep. beztween teams Teams need to wait for each other

Micro frontends: Agreement on technology choices TEams can work indepently

UX vs time to market (monolith) (micro frontends)

!Alles hat seinen Preis

Wie entscheidet man sich?

Drei Layer von Architekturprinzipien

Business (ttm vs ux) Autonome Teams, macro/micro Stateless, RESTful

Was ist für das Unternehmen am wichtigsten? - Zurückführen von Entscheidungen auf die Ziele und Architekturprinzipien

Reusability

Big UI Monolits -> schlecht Little frontends -> nur wenige Teams teilen sich einen Teil der UI, möglich

Decomposed UI -> "rechts"

Shared UI -> jedes Team baut eigene Microfrontends oder Komponenten, diese können quer durcheinander gehen. Wiederverwendung von Komponenten

Re-use versus decomposition

Simple UI -> Complex UI x-Achse Generic UI -> Specific UI y-Achse

Living styleguide -> UI Lib -> Snippets -> Intelligent Components -> User journey

Lohnt es sich wiederverwendbare fachliche Komponenten zu bauen? -> gerade bei komplexen wiederverwendbaren Komponenten -> kein Bedarf

Wiederverwendbarkeit nur in gleichem Bounded Context

Wiederverwendbarkeit nur bei selber Benutzergruppe mit selben Anforderungen

Wie teuer ist die Kopplung der Services? - Funktionale Aufteilung ist gut für die autonomie - besser Dinge mehrfach bauen

Backends for Frontends: Backends erfüllen spezifische Anforderungen von UIs (unterschied mobiles Netzwerk vs. W-Lan) optional: Service API bildet Domäne ab UND self contained systems autonome web applikationen service api ist optional FALSCH! Service API bildet Domäne ab

Widerspruch: Domäne richtig darstellen und nur bei Bedarf spezielle APIs

Fachlichkeit ist das stabilste was es gibt, neue Produkte rund um bestehende Fachlichkeit. Daher fachliches Fundament sauber abbilden

Wie Microfrontends implementieren

viele unterschiedliche Möglichkeiten um sie in der Praxis umzusetzen, auch einfache, machmal reichen diese auch aus

Aufwand höher -> kontinuierliches Testen erforderlich (automatisiert)

Absprechen, falls alle die gleiche Technologie nutzen müssen um alles zusammenbauen.

Lösung: Runtime Module loading,

Problem: Kommunikation zwischen Microfrontends:

Integration - verschiedene Möglichkeiten

Message posting mit react (bspw. zwischen iframes) - ohne Backend

Event Bus (Eev Framework) Komponenten können events werfen und hören - ohne Backend

Kommunikation (bspw. Http-Calls) über das Backend auch zu fremden MS

Wenn das nicht gewünscht ist, und nur mit dem eigenen MS geredet werden soll -> Integration im Backend

Vorteile Integration im Frontend (billiger nur lokal, weniger Aufwändig nur Änderungen im Frontend erforderlich) Vorteile Integration im Backend (möglicherweise passgenauer, Änderungen im Front und Backend erforderlich, automatische Abarbeitung von längerdauerneden Prozessstrukturen im Backend erledigen)

Nachdenken: Wo gehört das am besten hin? (sehr automatisiert -> Backend)

Sheet 35! --> Anschauen (~1h)

Frameworks die Technologiefreiheit erlauben -> UX Fragmentation

SPA (Single page application)

Ende zu Ende Testen ein Problem bei MS, keine wirklich gute Lösung bei mehr als 3-4 Teams, wird daher oft vernachlässigt

Komplexität im Betrieb -> Lösung automatisierung

Komponentenbildung genau durchdenken, keine unnötige Aufteilung in Komponenten

Wichtigstes Kriterium: Business value; Nutzen für das Produkt/Unternehmen