Kapitel II · Bereich 05 von 12
Die Frage an unseren ShopBleibt der Shop ein modularer Monolith, oder wird der Versand ein eigener Dienst?
Hier findest du Architekturstile und Muster mit ihrem Nutzen, ihren Voraussetzungen und ihren Folgen.
8 Bausteine
Hier anfangenLayered ArchitectureWie wird der Shop als Ganzes geschnitten und ausgeliefert?
Sieben Module, ein Deployment; der Versand als eigener Dienst ist eine geprüfte Variante.
Wie ist ein Modul innen aufgebaut?
Checkout in vier Schichten; Zahlung mit Port und Anbieteradapter.
Wie fließen Änderungen und Daten?
BestellungBezahlt weckt Versand und Rechnung; der CSV-Import läuft in Schritten.
Bekannte Namen – und wo sie stecken
Der modulare Monolith ist das Zentrum. Schichten und Hexagonal bauen seine Module innen auf, Microservices lösen einzelne Module heraus. Event-driven, CQRS, Event Sourcing und Pipe & Filter regeln, wie Änderungen und Daten fließen.
Architekturstile beantworten verschiedene Fragen: wie der Shop als Ganzes geschnitten wird, wie ein Modul innen aufgebaut ist und wie Daten fließen. Du kannst sie kombinieren, etwa Hexagonal im Zahlungsmodul eines modularen Monolithen. Jeder Baustein zeigt sein Thema an unserem Shop.
Das lernst duDu kannst eine Shop-Funktion einer Darstellungs-, Anwendungs-, Fach- oder Infrastrukturaufgabe zuordnen.
Im ShopDer Checkout des modularen Shop-Monolithen nimmt eine Bestellung an, prüft Fachregeln und speichert das Ergebnis in SQL.
Layered Architecture öffnenDas lernst duDu kannst für alle sieben Shop-Module eine Verantwortung und einen erlaubten Übergang benennen.
Im ShopDer Ausgangsshop liefert Katalog, Warenkorb, Bestellung, Zahlung, Lager, Versand und Rechnung gemeinsam aus. Nur der Zahlungsanbieter liegt außerhalb.
Modularer Monolith öffnenDas lernst duDu kannst anhand von Änderungs- und Betriebsbedarf begründen, ob ein Shop-Modul einen eigenen Dienst rechtfertigt.
Im ShopVariante: Der Shop trennt den Versand als eigenen Dienst ab, weil ein separates Team ihn unabhängig veröffentlicht und skaliert. Die übrigen sechs Module bleiben im modularen Monolithen; der Zahlungsanbieter bleibt extern.
Microservices öffnenDas lernst duDu kannst Fachkern, Port und Adapter für eine Zahlungsanbindung unterscheiden.
Im ShopDas interne Zahlungsmodul des modularen Monolithen entscheidet über Zahlungszustände. Ein Anbieteradapter übersetzt seinen Port in die externe API.
Hexagonale Architektur öffnenDas lernst duDu kannst für ein Bestellereignis Produzent, Ereignisinhalt und unabhängige Reaktionen benennen.
Im ShopIm modularen Monolithen veröffentlicht Bestellung intern das Ereignis BestellungBezahlt. Versand und Rechnung reagieren mit eigenen Aufgaben.
Event-driven Architecture öffnenDas lernst duDu kannst ein Schreibmodell und eine Leseansicht für dieselbe Bestellung mit unterschiedlichen Feldern entwerfen.
Im ShopBestellung prüft Statusübergänge im Schreibmodell. Der Kundenservice liest eine flache Übersicht mit Zahlung, Versand und Rechnungsnummer.
CQRS öffnenDas lernst duDu kannst den aktuellen Bestellstatus aus einer geordneten Ereignisfolge ableiten.
Im ShopEine experimentelle Bestellkomponente speichert jede akzeptierte Änderung an B-1042 als Ereignis. Der übrige Shop bleibt ein modularer Monolith.
Event Sourcing öffnenDas lernst duDu kannst einen Produktimport in Schritte mit eindeutigen Ein- und Ausgaben zerlegen.
Im ShopDer Katalog importiert jeden Morgen eine CSV-Datei mit neuen Tassen. Ungültige Zeilen sollen protokolliert werden, ohne gültige Produktdaten zu verfälschen.
Pipe & Filter öffnenDiese Bereiche hängen fachlich direkt mit Stile & Muster zusammen.