WASP1: Microservices und Event-getriebene Architektur (MEA), WS26
Achtung, diese Seite ist noch im Entwurfs-Stadium. Bitte beachten Sie, dass sich der Inhalt noch ändern kann.
“Microservices und Event-getriebene Architekturen” ist eine Wahlspezialisierung 1 (WASP1, 15 ECTS) im Informatik-Bachelor der TH Köln. Ausgehend von der Restaurant-Fallstudie aus ST2 erkunden die Studierenden die Domäne mit EventStorming, schneiden sie in Services, legen deren Events als AsyncAPI-Contracts fest, und implementieren und betreiben die Services auf Basis von Apache Kafka in einer gemeinsamen Laufzeitumgebung. Anschließend übertragen sie das Gelernte auf einen Player-Service im Microservice Dungeon.
- Studiengang und Modulbeschreibung
-
Informatik Bachelor
- Zeitraum und zeitliche Organisation der Veranstaltung
-
15.10.2026 - 18.02.2027. Ganztägige Workshops donnerstags, bis Anfang November wöchentlich, danach etwa alle zwei Wochen. Dazwischen arbeiten Sie selbstorganisiert in Ihren Teams. Der Grundlagenteil endet am 26.11.2026, die ganze Veranstaltung Anfang Februar. Planen Sie im Schnitt etwa 2 bis 2,5 Tage pro Woche ein, wenn Sie beide Teile belegen.
- Ort der Veranstaltung
- Die Veranstaltung findet in Präsenz statt. In Ausnahmefällen (aber nur wenn explizit für den Tag kommuniziert) weichen wir auf eine Remote-Option (Videokonferenz) aus. Wenn mehrere Räume angegeben sind, dann schauen schauen Sie bitte bei dem jeweiligen Zeitschlitz oder Workshoptag nach (siehe unten auf dieser Seite), welcher Raum an welchem Tag genutzt wird. Falls auf dieser Seite keine Angaben sind, prüfen Sie bitte die sonstigen Kommunikationkanäle für diese Veranstaltung (z.B. Discord).
-
-
Anmeldung
zur Veranstaltung
-
Bitte werden Sie Mitglied
in diesem ILIAS/ILU-Kurs.
Die Deadline ist tbd.
- Maximale / minimale Teilnehmerzahl
-
Die maximale Teilnehmerzahl ist
14.
Bei weniger als
5
Teilnehmer*innen kann die Veranstaltung leider nicht stattfinden.
- Discord-Server für schnelle Kommunikation
-
Discord hat sich als sehr effektive Plattform für den Informationsaustausch, Diskussionen und Fragen an Lehrende/Betreuer:innen erwiesen. Deshalb sollten Sie dem ArchiLab-Discord-Server beitreten unter
https://discord.gg/YYNYb5whU8.
Navigieren Sie zum Channel
#rollenzuweisung
und klicken Sie auf
mea und msd.
Die entsprechenden Kanäle zur Veranstaltung werden anschließend für Sie freigeschaltet.
- Youtube-Kanal
-
Für diese Veranstaltung sind Lehrvideos auf Youtube verfügbar. Abonnieren Sie dafür am besten den Kanal
ArchiLab.
Für die Videos zu dieser Veranstaltung gibt es eine
Playlist.
(Disclaimer - die Videos auf diesem Kanal sind nicht monetarisiert. Weder ich persönlich noch das Labor ArchiLab verdienen damit Geld. Wir nutzen YouTube vor allem deshalb, weil es für Studierende ein leicht zugänglicher Kanal ist. Außerdem bekommen wir als Labor an der TH Köln so auch Sichtbarkeit nach außen, was z.B. bei dem Einwerben von externen Gastvorträgen hilft.)
Learning Outcome
Die Wahlspezialisierung führt Sie von der Erkundung einer Domäne bis zu einem laufenden System aus Microservices, die über Events zusammenarbeiten, und überträgt das Gelernte danach auf eine Microservice-Landschaft, die es schon gibt.
Als Software-Entwickler:in im Team eines verteilten Microservice-Systems kann ich ein verteiltes System aus fachlich geschnittenen Microservices entwerfen, implementieren und betreiben, die vorrangig asynchron über Events kommunizieren,
indem ich ...
- an einem konkreten System Vor- und Nachteile von Microservices gegenüber einem Monolithen und einem Modulithen benenne,
- eine fachliche Domäne in einem EventStorming-Workshop gemeinsam erkunde,
- die Services eines Systems fachlich schneide und ihre Zusammenarbeit als Austausch von Events entwerfe,
- Services implementiere, die Events über Kafka veröffentlichen und konsumieren,
- Services automatisiert baue, als Container ausliefere und in einer gemeinsamen Umgebung betreibe,
- einen Player-Service für den Microservice Dungeon entwickle, der auf Events fremder Services reagiert,
- mit einem AI-Agenten wie Claude Code im Team so arbeite, dass das, was er liefert, vom Event-Contract bis zum Code, zur vereinbarten Architektur passt,
damit ich in einem solchen System verantwortlich mitarbeiten und einschätzen kann, wann sich dieser Architekturstil lohnt und wann nicht.
Die Kompetenzen im Einzelnen
Jede Kompetenz ist in Teilkompetenzen zerlegt. Bei den feinsten steht, woran Sie merken, dass Sie sie beherrschen, mit welchem Material Sie sie lernen, und wo in der Veranstaltung sie drankommt.
- Vor- und Nachteile von Microservices gegenüber einem Monolithen und einem Modulithen an einem konkreten System benennen (verstehen)
Daran merken Sie, dass Sie es können, Material, Wann
Daran merken Sie, dass Sie es können:
- kann für das Restaurant-System aus ST2 eine Änderung nennen, die als Monolith billiger wäre, und eine, die als Microservice-System billiger wäre, und jeweils sagen warum
Material:
Wann: Phase 1: Domänen-Exploration, Workshop am 15.10.2026
- eine fachliche Domäne in einem EventStorming-Workshop gemeinsam erkunden und das Ergebnis als Zeitleiste von Domain Events mit Kandidaten für Subdomänen-Grenzen dokumentieren (anwenden)
Daran merken Sie, dass Sie es können, Material, Wann
Daran merken Sie, dass Sie es können:
- kann auf dem Board ein Pivotal Event zeigen und sagen, welche beiden Teile des Ablaufs es voneinander trennt
- kann einen Ablauf nennen, der in ST2 ein synchroner Aufruf war, und das Event zeigen, das ihn auf dem Board ersetzt
- kann zeigen, woran man auf dem digitalen Board ohne Erklärung erkennt, was ein Event, ein Command, ein Hotspot und ein Pivotal Event ist, so dass Menschen und ein Agent es gleich lesen
Material:
Wann: Phase 1: Domänen-Exploration, Workshop am 15.10.2026
- die Services eines Systems fachlich schneiden und ihre Zusammenarbeit als Austausch von Events entwerfen (entwerfen)
- Bounded Contexts aus dem EventStorming-Ergebnis ableiten, jedem genau einen Service zuordnen und festhalten, welche Events die Grenzen zwischen ihnen überqueren (analysieren)
Daran merken Sie, dass Sie es können, Material, Wann
Daran merken Sie, dass Sie es können:
- kann für den eigenen Service einen Begriff nennen, der in ihm etwas anderes bedeutet als im Nachbar-Service, und sagen, warum die Grenze genau dort liegt
Material:
Wann: Phase 2: Bounded Contexts und Event-Contracts, Workshop am 22.10.2026
- die Events eines Service als dessen öffentliche Schnittstelle entwerfen, mit Name, Inhalt, Topic und den Services, die sie konsumieren (entwerfen)
Daran merken Sie, dass Sie es können, Material, Wann
Daran merken Sie, dass Sie es können:
- kann im Event-Katalog ein Event des eigenen Service zeigen und begründen, welche Daten es mitführt und welche bewusst nicht
Material:
Wann: Phase 3: Architekturkonzept und Walking Skeleton, Workshop am 29.10.2026
- redundante Daten in mehreren Services bewusst halten und benennen, wo das System dadurch nur schließlich konsistent ist (analysieren)
Daran merken Sie, dass Sie es können, Material, Wann
Daran merken Sie, dass Sie es können:
- kann eine Kopie fremder Daten im eigenen Service zeigen, sagen, durch welches Event sie aktuell gehalten wird, und was ein Gast sieht, solange sie veraltet ist
Material:
Wann: Phase 4: Implementierung und Betrieb, Workshop am 10.12.2026
- einen Service implementieren, der Events über Kafka veröffentlicht und konsumiert (entwerfen)
- Topics, Partitionen, Consumer Groups und Offsets erklären und daraus ableiten, in welcher Reihenfolge ein Service Events zu sehen bekommt (verstehen)
Daran merken Sie, dass Sie es können, Material, Wann
Daran merken Sie, dass Sie es können:
- kann für ein Topic des eigenen Systems sagen, nach welchem Key es partitioniert ist, welche Reihenfolge das garantiert und welche nicht
Material:
Wann: Phase 3: Architekturkonzept und Walking Skeleton, Workshop am 29.10.2026
- Events mit der bereitgestellten Hilfsbibliothek oder einer eigenen Implementierung veröffentlichen und konsumieren, so dass ein doppelt zugestelltes Event keinen Schaden anrichtet (anwenden)
Daran merken Sie, dass Sie es können, Material, Wann
Daran merken Sie, dass Sie es können:
- kann im Code des eigenen Service den Consumer zeigen und vorführen, was passiert, wenn dasselbe Event zweimal ankommt
Material:
Wann: Phase 4: Implementierung und Betrieb, Workshop am 26.11.2026
- einen Service automatisiert bauen, als Container ausliefern und in einer gemeinsamen Umgebung zusammen mit den anderen Services betreiben (anwenden)
- für den eigenen Service ein Container-Image bauen, das ohne lokale Voraussetzungen startet und seine Konfiguration aus der Umgebung bezieht (anwenden)
Daran merken Sie, dass Sie es können, Material, Wann
Daran merken Sie, dass Sie es können:
- kann zeigen, welche Einstellung des Service beim Start aus der Umgebung kommt, und sie ohne neuen Build ändern
Material:
Wann: Phase 3: Architekturkonzept und Walking Skeleton, Workshop am 05.11.2026
- eine Pipeline aufsetzen, die bei jedem Push baut, testet und ein Image veröffentlicht (anwenden)
Daran merken Sie, dass Sie es können, Material, Wann
Daran merken Sie, dass Sie es können:
- kann einen roten Pipeline-Lauf zeigen und sagen, welche Stufe verhindert hat, dass ein defektes Image in der gemeinsamen Umgebung landet
Material:
Wann: Phase 3: Architekturkonzept und Walking Skeleton, Workshop am 05.11.2026
- den eigenen Service in die gemeinsame Laufzeitumgebung bringen und nachweisen, dass er mit den anderen Services über Events zusammenarbeitet (anwenden)
Daran merken Sie, dass Sie es können, Material, Wann
Daran merken Sie, dass Sie es können:
- kann vorführen, was der eigene Service tut, wenn Kafka oder ein Nachbar-Service beim Start noch nicht verfügbar ist
Material:
Wann: Phase 4: Implementierung und Betrieb, Workshop am 17.12.2026
- einen Player-Service für den Microservice Dungeon implementieren, der ausschließlich auf Events fremder Services reagiert, deren Verträge er nicht mitbestimmen kann (entwerfen)
Daran merken Sie, dass Sie es können, Material, Wann
Daran merken Sie, dass Sie es können:
- kann zeigen, wo der eigene Player sein Bild der Spielwelt aus Events aufbaut, und sagen, was er tut, wenn dieses Bild veraltet ist
Material:
Wann: Phase 5: Microservice Dungeon, Workshop am 07.01.2027
- mit einem AI-Agenten wie Claude Code im Team so arbeiten, dass das, was der Agent liefert, vom Event-Contract bis zum Code, zur vereinbarten Architektur passt (entwerfen)
- aus einem dokumentierten Modellierungsergebnis, etwa einem EventStorming-Board, von einem AI-Agenten einen ersten Event-Contract entwerfen lassen und den Entwurf gegen das Board und den Service-Schnitt prüfen, bevor er gilt (bewerten)
Daran merken Sie, dass Sie es können, Material, Wann
Daran merken Sie, dass Sie es können:
- kann im AsyncAPI-Contract des eigenen Service eine Stelle zeigen, an der das Team den Entwurf des Agenten geändert oder verworfen hat, und sagen, welche Information auf dem Board dafür fehlte oder missverständlich war
Material:
Wann: Phase 2: Bounded Contexts und Event-Contracts, Workshop am 22.10.2026
- für das eigene Repository die Konventionen und Berechtigungen festlegen, mit denen der Agent arbeitet, und sie pflegen, wenn der Agent etwas falsch macht (anwenden)
Daran merken Sie, dass Sie es können, Material, Wann
Daran merken Sie, dass Sie es können:
- kann in den Konventionen des eigenen Repositorys eine Regel zeigen, die hinzukam, weil der Agent etwas falsch gemacht hat, und sagen, was sie jetzt verhindert
Material:
Wann: Phase 3: Architekturkonzept und Walking Skeleton, Workshop am 05.11.2026
- Architekturregeln des eigenen Service als automatisierte Prüfungen in der Pipeline formulieren, so dass Code, der sie verletzt, nicht durchkommt, egal wer ihn geschrieben hat (entwerfen)
Daran merken Sie, dass Sie es können, Material, Wann
Daran merken Sie, dass Sie es können:
- kann eine Prüfung zeigen, die eine Grenze aus dem Service-Schnitt absichert, und sie an einer absichtlichen Verletzung fehlschlagen lassen
Material:
Wann: Phase 4: Implementierung und Betrieb, Workshop am 26.11.2026
- im Team festlegen, was ein Mensch prüft, bevor Code des Agenten gemergt wird, und warum die Grenze genau dort liegt (anwenden)
Daran merken Sie, dass Sie es können, Material, Wann
Daran merken Sie, dass Sie es können:
- kann für den eigenen Service sagen, was vor einem Merge von einem Menschen gelesen wird, was die Pipeline prüft, und was keiner von beiden
Material:
Wann: Phase 4: Implementierung und Betrieb, Workshop am 26.11.2026
Phasen im Überblick
Grundlagenteil (5 ECTS)
Domäne erkunden, in Services schneiden, Event-Contracts festlegen, und ein Walking Skeleton in der gemeinsamen Umgebung zum Laufen bringen.
| Phase | Zeitraum (nach Workshops) | Was entsteht | Team |
|---|
Phase 1: Domänen-Exploration
Grundlagenteil. Wir erkunden die Restaurant-Domäne neu, diesmal mit dem Blick auf Events statt auf Aufrufe, und erweitern sie um Abläufe, die es in ST2 noch nicht gab.- Kompetenzen:
- Vor- und Nachteile von Microservices gegenüber einem Monolithen und einem Modulithen an einem konkreten System benennen
- eine fachliche Domäne in einem EventStorming-Workshop gemeinsam erkunden und das Ergebnis als Zeitleiste von Domain Events mit Kandidaten für Subdomänen-Grenzen dokumentieren
| 15.10.2026 | - Dokumentation des EventStorming-Ergebnisses
| alle gemeinsam |
Phase 2: Bounded Contexts und Event-Contracts
Grundlagenteil. Aus dem EventStorming werden Bounded Contexts, und aus jedem Bounded Context wird der Service eines Teams. Jedes Team legt die Events seines Service als AsyncAPI-Contract fest.- Kompetenzen:
- Bounded Contexts aus dem EventStorming-Ergebnis ableiten, jedem genau einen Service zuordnen und festhalten, welche Events die Grenzen zwischen ihnen überqueren
- aus einem dokumentierten Modellierungsergebnis, etwa einem EventStorming-Board, von einem AI-Agenten einen ersten Event-Contract entwerfen lassen und den Entwurf gegen das Board und den Service-Schnitt prüfen, bevor er gilt
| 22.10.2026 | - Schnitt in Bounded Contexts und ihre Beziehungen
- AsyncAPI-Contract des eigenen Service
| alle gemeinsam
Service-Team |
Phase 3: Architekturkonzept und Walking Skeleton
Grundlagenteil, Abschluss. Die AsyncAPI-Contracts der Teams werden zum Event-Katalog des Systems, und wir legen fest, wie die Services gebaut und betrieben werden. Am Ende läuft ein Walking Skeleton, in dem jeder Service mindestens ein Event über die gemeinsame Umgebung austauscht, und jede:r reflektiert den Grundlagenteil. Die Phase endet am Vormittag des 26.11.2026, dem Tag, an dem der Projektteil beginnt.- Kompetenzen:
- die Events eines Service als dessen öffentliche Schnittstelle entwerfen, mit Name, Inhalt, Topic und den Services, die sie konsumieren
- Topics, Partitionen, Consumer Groups und Offsets erklären und daraus ableiten, in welcher Reihenfolge ein Service Events zu sehen bekommt
- für den eigenen Service ein Container-Image bauen, das ohne lokale Voraussetzungen startet und seine Konfiguration aus der Umgebung bezieht
- eine Pipeline aufsetzen, die bei jedem Push baut, testet und ein Image veröffentlicht
- für das eigene Repository die Konventionen und Berechtigungen festlegen, mit denen der Agent arbeitet, und sie pflegen, wenn der Agent etwas falsch macht
- Meilenstein: Das Walking Skeleton läuft, 26.11.2026 10:00
| 29.10.2026
05.11.2026 | - Event-Katalog des Systems
- Konzept für Pipelines und Laufzeitumgebung
- Walking Skeleton des eigenen Service, mit Repository, Konventionen für den Agenten und dokumentierten Entwurfsentscheidungen
- Reflexion des Grundlagenteils
| alle gemeinsam
Service-Team |
Projektteil (10 ECTS)
Das Restaurant-System als Microservices ausbauen und betreiben, danach ein Player-Service im Microservice Dungeon. (setzt voraus Grundlagenteil)
| Phase | Zeitraum (nach Workshops) | Was entsteht | Team |
|---|
Phase 4: Implementierung und Betrieb
Projektteil. Die Teams bauen ihre Services aus und betreiben sie von Anfang an in der gemeinsamen Umgebung. Die Workshops verbinden jeweils einen Input mit Co-Located Coding, und jeder endet mit einer Integration.- Kompetenzen:
- Architekturregeln des eigenen Service als automatisierte Prüfungen in der Pipeline formulieren, so dass Code, der sie verletzt, nicht durchkommt, egal wer ihn geschrieben hat
- im Team festlegen, was ein Mensch prüft, bevor Code des Agenten gemergt wird, und warum die Grenze genau dort liegt
- Events mit der bereitgestellten Hilfsbibliothek oder einer eigenen Implementierung veröffentlichen und konsumieren, so dass ein doppelt zugestelltes Event keinen Schaden anrichtet
- redundante Daten in mehreren Services bewusst halten und benennen, wo das System dadurch nur schließlich konsistent ist
- den eigenen Service in die gemeinsame Laufzeitumgebung bringen und nachweisen, dass er mit den anderen Services über Events zusammenarbeitet
- Meilenstein: Das Restaurant-System läuft zusammen, 07.01.2027 10:00
| 26.11.2026
10.12.2026
17.12.2026 | - Der Service des eigenen Teams
- Pipeline und Deployment des eigenen Service
- Konventionen, Berechtigungen und Architekturprüfungen, mit denen das Team den Agenten einsetzt
| Service-Team |
Phase 5: Microservice Dungeon
Projektteil. Microservice-Entwicklung in einer Landschaft, die es schon gibt: Im Dungeon reagieren Sie auf Events, die andere entworfen haben, und konzentrieren sich auf eine gute Strategie für Ihren Player. Dazu fortgeschrittene Themen aus Betrieb und Hosting. Zum Schluss reflektieren wir, ob dieser Architekturstil etwas für Sie ist.- Kompetenzen:
- einen Player-Service für den Microservice Dungeon implementieren, der ausschließlich auf Events fremder Services reagiert, deren Verträge er nicht mitbestimmen kann
| 07.01.2027
21.01.2027
04.02.2027
18.02.2027 | | |
Worum es geht
In ST2 haben Sie ein Restaurant-System gebaut, in dem ein Teil den anderen
direkt aufruft und auf die Antwort wartet. In MEA bauen wir dasselbe System noch einmal, erweitert um
neue Abläufe, aber als Menge von Microservices, die nicht aufeinander warten: Jeder Service meldet,
was in seinem Bereich passiert ist, und die anderen entscheiden selbst, was sie damit anfangen. Die
Services sind dadurch loser gekoppelt als die Module in ST2 und können sich auf ihre eigene Aufgabe
konzentrieren.
Das ist eine andere Art, über Abläufe nachzudenken. Sie erfordert Umdenken, und die Gewöhnung daran
ist eines der Lernziele dieses Moduls. Außerdem ist der technische Aufwand deutlich höher als in einem
Monolithen. Kafka, Container und Pipelines sind die Werkzeuge dafür.
Die Veranstaltung verläuft in fünf Phasen.
- Domänen-Exploration: Wir erkunden die Restaurant-Domäne an einem EventStorming-Tag neu.
- Bounded Contexts und Event-Contracts: Wir schneiden die Domäne in Bounded Contexts, jedes Team
übernimmt einen davon als Service und beschreibt dessen Events als AsyncAPI-Contract.
- Architekturkonzept und Walking Skeleton: Aus den Contracts wird der Event-Katalog des Systems, und
jeder Service tauscht über seine Pipeline ein erstes Event in der gemeinsamen Umgebung aus.
- Implementierung und Betrieb: Die Teams bauen ihre Services aus und betreiben sie dabei von Anfang
an, bis das ganze Restaurant-System zusammen läuft. Entwicklung und Betrieb laufen hier bewusst
nicht nacheinander, sondern miteinander, und die Arbeit mit dem Agenten im Team rückt in den
Mittelpunkt.
- Microservice Dungeon: Sie entwickeln einen Player-Service in einer Microservice-Landschaft, die es
schon gibt, und treten in Codefights gegeneinander an. Dazu kommen fortgeschrittene Themen wie
Infrastructure as Code und Monitoring. Zum Schluss reflektieren wir, ob dieser Architekturstil etwas
für Sie ist.
Claude Pro für Ihre Projektarbeit
Für die Zeit Ihrer Arbeit an diesem Projekt bekommen Sie kostenlos einen Claude-Pro-Zugang, und
damit auch Claude Code. Möglich ist das durch den Anthropic Team Plan for Scientists, ein Programm
für 10.000 Wissenschaftlerinnen und Wissenschaftler weltweit, in das ich aufgenommen wurde.
Wie man im Team mit agentischer KI so arbeitet, dass der Code zur Architektur passt, ist deshalb
auch ein Thema der Veranstaltung: angelegt im Grundlagenteil, wenn Sie Ihr Repository aufsetzen, und
vertieft im Projektteil.
Grundlagen- und Projektteil
MEA ist eine Wahlspezialisierung aus zwei Teilen, die aufeinander aufbauen. Jeder Teil hat seine
eigene Note.
- Der Grundlagenteil (5 ECTS) umfasst die Phasen 1 bis 3, von Mitte Oktober bis Ende November. Er
endet mit einem Architekturkonzept für das Restaurant-System, einem laufenden Walking Skeleton und
einer Reflexion.
- Der Projektteil (10 ECTS) umfasst die Phasen 4 und 5, von Ende November bis Anfang Februar. In ihm
wird das Konzept bis Anfang Januar zum laufenden System, und danach geht es in den Microservice
Dungeon.
Sie können nach dem Grundlagenteil aufhören und bekommen dafür eine eigene Note. Umgekehrt geht es
nicht: Der Projektteil setzt den Grundlagenteil voraus.
Termine und Arbeitsweise
Die Workshops finden donnerstags statt, als ganze Tage vor Ort. Bis Anfang November treffen wir uns
wöchentlich, weil die Schritte von der Domänen-Exploration bis zum Konzept für das Walking Skeleton
direkt aufeinander aufbauen. Nach dem 05.11.2026 haben die
Teams drei Wochen ohne Termin, um ihr Walking Skeleton fertigzustellen. Am 26.11.2026 wechseln wir
vom Grundlagen- in den Projektteil: vormittags Abschluss des Grundlagenteils, nachmittags der Start
des Projektteils. Im Projektteil treffen wir uns etwa alle zwei Wochen. Ein Workshop besteht dann aus
einem Input, gemeinsamem Coding vor Ort, und einer Integration am Ende des Tages, bei der die
Services der Teams zusammen laufen müssen. Am 07.01.2027, in der Blockwoche, wechseln wir noch
einmal: vormittags die Abschlussvorführung des Restaurant-Systems, nachmittags der Kickoff für den
Microservice Dungeon.
Es gibt keine formale Anwesenheitspflicht, aber ohne Anwesenheit ergibt dieses Modul wenig Sinn.
Teams
Jedes Team setzt einen Bounded Context als Service um. Wie viele Teams es gibt und wie groß sie sind,
hängt davon ab, wie viele Sie sind, und wird am 22.10.2026 festgelegt. Jedes Team ist für seinen
Service vollständig selbst verantwortlich, einschließlich Pipeline und Betrieb. Es gibt kein
DevOps-Team, das das für andere erledigt; stattdessen übernimmt in jedem Team eine Person die
Infrastruktur federführend. Ob für den Microservice Dungeon dieselben Teams bestehen bleiben oder neu
gemischt wird, entscheiden wir gemeinsam, wenn es so weit ist.
Die Fallstudie
Ausgangspunkt ist das Restaurant-System aus ST2, beschrieben in der
Fallstudie. Für MEA erweitern wir es um Abläufe,
die ohne Events nur mühsam zu bauen wären. Welche das werden, entscheiden wir am EventStorming-Tag
gemeinsam. Kandidaten sind:
- Warmhalteboxen: Die Küche stellt ein fertiges Gericht in eine Box, und der Gast holt es dort ab,
ohne mit der Küche zu tun zu haben. Dafür muss klar sein, in welcher Box welches Essen liegt und wie
der Gast die richtige Box findet.
- Lager: Zutaten werden verbraucht, gehen zur Neige und müssen nachbestellt werden.
- Mehr Realismus: Heute müssen zum Beispiel alle Gäste eines Tisches gleichzeitig gehen, was im
echten Restaurant niemand tut.
Ihren Code aus ST2 dürfen Sie gern als Ausgangspunkt verwenden.
Das technische Setting
Die Kafka-Infrastruktur stellen wir Ihnen bereit. Für Java gibt es Hilfsbibliotheken, unter anderem
für Kafka-Consumer und -Producer. Sie dürfen Ihren Service auch in einer anderen Sprache schreiben.
Dann bauen Sie die nötigen Hilfsfunktionen selbst nach, und der Event-Katalog des Systems ist der
Contract, an den Sie sich halten. Als gemeinsame Laufzeitumgebung ist Docker Compose auf einem
gemeinsamen Server vorgesehen.
Bewertung
Die Bewertungstabelle ist ein Entwurf und wird bis zum Start ausgearbeitet. Jedes Kriterium wird auf
derselben Skala von 0 bis 3 Punkten bewertet, mit halben oder viertel Punkten dazwischen. Daraus wird
das nach den Gewichten gewichtete Mittel gebildet: Ab 2,75 Punkten gibt es eine 1,0, bei 1 Punkt eine
4,0, und dazwischen wird interpoliert. Grundlagen- und Projektteil werden getrennt benotet, der
Projektteil mit etwa dem doppelten Gewicht.
Im Projektteil zählen das Restaurant-System und der Microservice Dungeon gleich viel. Der Schnitt des
Systems im Grundlagenteil wird für alle gemeinsam bewertet, denn er ist das Ergebnis des
EventStorming-Workshops.
Bewertungstabelle: Grundlagenteil (5 ECTS)
| Teil | Kriterium | Gewicht | 0 Punkte | 1 Punkte | 2 Punkte | 3 Punkte |
|---|
Schnitt des Systems in Bounded Contexts
Eine gemeinsame Bewertung für alle Teilnehmenden, denn der Schnitt ist das Ergebnis des EventStorming-Workshops und der gemeinsamen Diskussion. | 1 | Die Bounded Contexts sind nicht aus dem EventStorming abgeleitet, sondern aus Tabellen oder Bildschirmen. | Der Schnitt ist erkennbar aus dem EventStorming abgeleitet, aber nicht begründet. | Der Schnitt ist fachlich begründet: Für jede Grenze lässt sich sagen, welche Sprache oder Verantwortung sich dort ändert. | Wie 2, und es ist festgehalten, welcher alternative Schnitt verworfen wurde und warum. |
| Event-Contracts des eigenen Service | 2 | Es gibt keinen nachvollziehbaren Contract, oder die Events sind Aufrufe in Verkleidung. | Der AsyncAPI-Contract existiert, aber viele Events befehlen dem Empfänger etwas, statt eine Tatsache zu melden, und ihr Inhalt ist nicht begründet. | Die Events des eigenen Service melden Tatsachen, sind im Event-Katalog vollständig beschrieben, und wo Daten redundant gehalten werden, ist das benannt. | Wie 2, und das Team kann für jedes Event sagen, welche Daten es bewusst nicht mitführt und warum. |
Infrastrukturkonzept und Walking Skeleton
Der Hauptteil der Arbeit im Grundlagenteil: die Arbeit planen, Repository und Pipeline aufsetzen, Entwurfsentscheidungen dokumentieren, und den Einsatz des Agenten vorbereiten. | 4 | Es gibt kein tragfähiges Konzept, und der eigene Service erreicht die gemeinsame Umgebung nicht. | Das Konzept ist lückenhaft. Der Service läuft in der gemeinsamen Umgebung, aber nur nach Handarbeit, und Entwurfsentscheidungen sind kaum dokumentiert. | Der Service kommt über seine Pipeline in die gemeinsame Umgebung und tauscht dort ein Event mit einem anderen Service aus. Die Entwurfsentscheidungen sind dokumentiert, und das Repository enthält Konventionen, mit denen ein Agent im Team arbeiten kann. | Wie 2, und das Team kann sagen, welche Entscheidung im Konzept es nach dem Walking Skeleton anders treffen würde, und warum. |
| Reflexion des Grundlagenteils | 1 | Die Reflexion erzählt nach, was gemacht wurde, ohne ein Urteil über die Denkweise. | Die Reflexion nennt Vor- und Nachteile der Event-getriebenen Architektur in allgemeinen Worten, die auf jedes Projekt passen würden. | Die Reflexion ist an dieser Fallstudie festgemacht: Sie sagt, wo das Denken in Events schwergefallen ist und wo es geholfen hat. | Wie 2, und sie sagt, unter welchen Bedingungen man diesen Stil nicht wählen würde, mit einem Grund aus der eigenen Erfahrung im Grundlagenteil. |
| Beteiligung an fachlichen Diskussionen und Interaktionen | 1 | Kaum sichtbar in der Veranstaltung, über die Pflichten im eigenen Team hinaus. | Im eigenen Team präsent, im Austausch zwischen den Teams aber nicht sichtbar. | Verlässlich präsent in Diskussionen und in der Hilfe zwischen den Teams, fragend wie antwortend. | Hat für andere sichtbar Teile der Veranstaltung mitgetragen, durch Anleiten, Entblocken und Helfen über das eigene Team hinaus. |
| Summe | 9 | Maximal erreichbare Punkte: 27 |
Bewertungstabelle: Projektteil (10 ECTS)
| Teil | Kriterium | Gewicht | 0 Punkte | 1 Punkte | 2 Punkte | 3 Punkte |
|---|
| Restaurant-System | Implementierung des eigenen Service
Es muss genug Code für eine Bewertung vorhanden sein. Ein Service, der kaum über das Walking Skeleton hinausgeht, wird mit höchstens 1 Punkt bewertet. | 4 | Der Service läuft nicht, oder er arbeitet mit anderen Services über direkte Aufrufe oder eine gemeinsame Datenbank zusammen statt über Events. | Der Service läuft und deckt einen Teil seiner Abläufe ab. Die Zusammenarbeit über Events funktioniert nur auf dem vorgeführten Pfad. | Der Service deckt seine Abläufe ab und arbeitet ausschließlich über Events mit den anderen zusammen, so wie im Event-Katalog vereinbart. Es gibt sinnvolle automatisierte Tests. | Wie 2, und der Service verhält sich vernünftig, wenn Events doppelt, verspätet oder gar nicht ankommen. Das ist als Entwurfsentscheidung sichtbar, nicht erst in der Demo entdeckt. |
| Pipeline und Betrieb des eigenen Service | 2 | Es gibt keine funktionierende Pipeline, und der Service läuft nur in der IDE. | Die Pipeline aus dem Walking Skeleton existiert, wurde aber nicht weiterentwickelt, und der Service läuft nicht zuverlässig in der gemeinsamen Umgebung. | Die Pipeline baut, testet und veröffentlicht bei jedem Push, und der Service läuft in der gemeinsamen Umgebung mit den anderen zusammen. | Wie 2, und der Service übersteht es, wenn Kafka oder ein Nachbar-Service kurzzeitig fehlt, und das Team kann zeigen, woran es das im Betrieb erkennt. |
| Arbeit mit dem Agenten im Team | 2 | Der Agent wurde als Orakel benutzt. Erzeugter Code wurde ungeprüft übernommen oder ganz verworfen, fehlschlagende Prüfungen wurden durch Aufweichen der Regel umgangen, und im Repository ist nicht festgehalten, wie das Team arbeitet. | Der Agent wurde mit etwas Sorgfalt eingesetzt, aber die Konventionen blieben, wie sie im Walking Skeleton angelegt waren. Eine fehlschlagende Prüfung wurde eher stummgeschaltet als verstanden. | Konventionen, Berechtigungen und Prüfungen gehörten zur Arbeit. Das Team hat sie erweitert, als der Service wuchs, und eine fehlschlagende Prüfung führte zu einer Entwurfsdiskussion statt zu einer Ausnahme. | Wie 2, und das Team kann einen Fall zeigen, in dem es entschieden hat, dass die Prüfung falsch war und die Regel geändert hat, oder dass der Code falsch war und den Code geändert hat. |
| Microservice Dungeon | Strategie und Features des Players | 4 | Der Player läuft nicht, oder er tut nichts, was über die zugelieferte Codebasis hinausgeht. | Der Player spielt sinnvoll, aber nur einen kleinen Teil des Spiels. | Der Player verfolgt eine erkennbare Strategie und beherrscht einen großen Teil der wesentlichen Spiel-Features. | Wie 2, und der Player hat etwas, das ihn von den anderen unterscheidet, in der Strategie oder in dem, was er kann. |
| Architektur und Qualität des Players | 2 | Die Architektur zeigt kein Verständnis für ein System, das über Events kommuniziert, und es gibt keine automatisierten Tests. | Das Bild der Spielwelt wird nur teilweise aus Events aufgebaut, und Tests gibt es nur vereinzelt. | Der Player baut sein Bild der Spielwelt sauber aus Events auf, ist fachlich geschnitten und hat einen sinnvollen Satz automatisierter Tests. | Wie 2, und der Player geht bewusst damit um, dass Events doppelt, verspätet oder in anderer Reihenfolge ankommen. |
| Deployment und Codefight | 2 | Der Player wurde nicht deployed. | Erste Schritte für das Deployment sind gemacht, aber der Player läuft nicht im gemeinsamen Dungeon. | Der Player läuft im gemeinsamen Dungeon, aber mit Problemen, und nimmt nicht an allen Codefights teil. | Der Player wird über eine Pipeline deployed und nimmt erfolgreich an den Codefights teil. |
| Abschlussreflexion | 1 | Die Reflexion erzählt nach, was gemacht wurde, ohne ein Urteil über den Architekturstil. | Die Reflexion nennt Vor- und Nachteile von Microservices in allgemeinen Worten. | Die Reflexion ist am eigenen Service und am eigenen Player festgemacht: Sie sagt, wo der Stil sich gelohnt hat und wo er mehr gekostet als gebracht hat. | Wie 2, und sie begründet aus der Erfahrung des Semesters, ob dieser Stil etwas für einen selbst ist und unter welchen Bedingungen man ihn wählen würde oder gerade nicht. |
| Beteiligung an fachlichen Diskussionen und Interaktionen | 1 | Kaum sichtbar in der Veranstaltung, über die Pflichten im eigenen Team hinaus. | Im eigenen Team präsent, im Austausch zwischen den Teams aber nicht sichtbar. | Verlässlich präsent in Diskussionen und in der Hilfe zwischen den Teams, fragend wie antwortend. | Hat für andere sichtbar Teile der Veranstaltung mitgetragen, durch Anleiten, Entblocken und Helfen über das eigene Team hinaus. |
| Summe | 18 | Maximal erreichbare Punkte: 54 |
Workshops "Phase 1: Domänen-Exploration"
Thu 15.10.2026, 10:00 - 17:00: Kickoff und EventStorming
Moderiert von: Lehrende. Nach einer kurzen Einführung in die Organisation erkunden wir die erweiterte Restaurant-Domäne gemeinsam in einem Big-Picture-EventStorming. Ich moderiere und zeige Ihnen dabei, wie die Methode funktioniert.
Die Inhalte können in diesem und diesem Foliensatz nachgelesen werden.
Ziel des Tages
Sie haben die Domäne als Zeitleiste von Events vor sich, sehen erste Kandidaten für die Grenzen zwischen Subdomänen, und wissen, wie man ein EventStorming durchführt.
Die nachfolgenden Videos bieten zusätzliche Informationen zum Thema
Agenda
-
10:00 - 11:00:
Kickoff
- Warum Microservices, und was ändert sich, wenn Services nicht mehr aufeinander warten?
- Phasen, Termine, Grundlagen- und Projektteil
-
11:00 - 16:30:
EventStorming
- Die Restaurant-Domäne aus ST2 und die Abläufe, die neu hinzukommen
- Mit Pausen, inklusive Mittagspause
-
16:30 - 17:00:
Retrospektive und Ausblick auf die Bounded Contexts
Aufgabe bis zum nächsten Workshop
- Übertragen Sie das EventStorming-Ergebnis in Kleingruppen auf das gemeinsame Miro-Board, jede Gruppe den Bereich, für den sie verantwortlich ist. Halten Sie sich an den Farbcode aus dem Workshop, ordnen Sie die Events von links nach rechts in der Zeit, und markieren Sie Pivotal Events und Hotspots so, dass man sie ohne Erklärung erkennt. Das Board hat zwei Leser: Ihre Kommiliton:innen und einen AI-Agenten, der daraus im nächsten Workshop einen ersten Event-Contract entwirft. Wer für den Konsistenz-Check verantwortlich ist, prüft am Ende, ob die Bereiche zusammenpassen.
- Klären Sie die Hotspots in Ihrem Bereich, aus der Fallstudie oder als Frage an mich in der Rolle des Kunden. Was sich nicht klären lässt, bleibt als Hotspot auf dem Board.
- Jede:r für sich: Suchen Sie in Ihrem ST2-Code drei synchrone Aufrufe zwischen Modulen und notieren Sie für jeden, welches Event ihn ersetzen würde. Bringen Sie die Liste am 22.10.2026 mit.
- Werkzeug-Check: Aktivieren Sie Ihren Claude-Pro-Zugang, installieren Sie Claude Code, verbinden Sie es mit dem Miro MCP Server, und prüfen Sie, dass Claude Code das Board lesen kann. Am 22.10.2026 arbeiten wir direkt damit.
Workshops "Phase 2: Bounded Contexts und Event-Contracts"
Thu 22.10.2026, 10:00 - 16:00: Bounded Contexts, Teambildung und ein erster Event-Contract mit dem Agenten
Moderiert von: Lehrende. Vormittags schneiden wir das digitalisierte EventStorming-Board in Bounded Contexts, bilden die Service-Teams und halten fest, welche Events die Grenzen zwischen ihnen überqueren. Nachmittags lässt jedes Team einen AI-Agenten das Board über den Miro MCP Server lesen und daraus einen ersten AsyncAPI-Contract für seinen Service entwerfen, und prüft diesen Entwurf kritisch gegen Board und Schnitt.
Ziel des Tages
Jedes Team weiß, welchen Bounded Context es als Service umsetzt, und hat einen geprüften ersten Entwurf seines AsyncAPI-Contracts.
Agenda
-
10:00 - 10:30:
Review des digitalisierten Boards
- Taugt das Board als Grundlage, für uns und für einen Agenten?
- Geklärte und offene Hotspots, Ihre ST2-Aufrufe und die Events, die sie ersetzen
-
10:30 - 11:00:
Input: Bounded Contexts
- Eine Grenze, an der sich Sprache und Verantwortung ändern
- Pivotal Events und Heuristiken, um Grenzen im EventStorming-Ergebnis zu finden
-
11:00 - 12:00:
Schnitt am Board und Teambildung
- Wir ziehen die Grenzen gemeinsam auf dem Miro-Board
- Jeder Bounded Context wird der Service eines Teams
- Wer übernimmt in jedem Team die Infrastruktur federführend?
-
12:00 - 12:30:
Welche Events überqueren welche Grenze?
- Auf dem Board festhalten, welcher Service ein Event veröffentlicht und welche es konsumieren
-
12:30 - 13:15:
Mittagspause
-
13:15 - 14:00:
Input: AsyncAPI, und Live-Demo mit dem Agenten
- Channels, Operations, Messages und ihr Payload
- Claude Code liest das Board über den Miro MCP Server und entwirft einen Contract, mit allem, was dabei schiefgeht
-
14:00 - 15:30:
Teamarbeit: Event-Contract entwerfen lassen und prüfen
- Jedes Team lässt den Agenten einen AsyncAPI-Entwurf für seinen Service erzeugen
- Prüffragen: Meldet jedes Event eine Tatsache, oder ist es ein Aufruf in Verkleidung? Trägt es die Daten, die die Konsumenten brauchen, und nicht mehr? Fehlt ein Konsument?
-
15:30 - 16:00:
Ein Befund pro Team, Ausblick und Hausaufgabe
Aufgabe bis zum nächsten Workshop
- Stellen Sie den AsyncAPI-Contract Ihres Service fertig, ausgehend vom Entwurf aus dem Workshop, und halten Sie fest, wo Sie vom Entwurf des Agenten abgewichen sind und warum.
Workshops "Phase 3: Architekturkonzept und Walking Skeleton"
Thu 29.10.2026, 10:00 - 16:00: Event-Katalog und Infrastrukturkonzept
Moderiert von: Lehrende. Wir legen die AsyncAPI-Contracts der Teams nebeneinander und machen daraus einen Event-Katalog für das ganze System. Dazu die Kafka-Grundlagen, die bereitgestellten Hilfsbibliotheken und das Konzept für Pipelines und Laufzeitumgebung.
Ziel des Tages
Der Event-Katalog steht in einer ersten Version, und das Infrastrukturkonzept ist abgestimmt.
Thu 05.11.2026, 10:00 - 16:00: Walking Skeleton
Moderiert von: Lehrende. Co-Located Coding und eine erste Integration: Jeder Service soll über seine Pipeline in die gemeinsame Umgebung kommen und dort sein erstes Event mit einem anderen Service austauschen. Danach haben die Teams drei Wochen ohne Termin, um das Walking Skeleton fertigzustellen. Am 26.11.2026 führen wir es vor und schließen den Grundlagenteil ab.
Ziel des Tages
Jedes Team weiß, was seinem Walking Skeleton noch fehlt, und hat einen Plan bis zum 26.11.2026.
Workshops "Phase 4: Implementierung und Betrieb"
Thu 26.11.2026, 10:00 - 16:00: Abschluss des Grundlagenteils und Agentic Development im Team
Moderiert von: Lehrende. Dieser Tag ist der Wechsel vom Grundlagen- zum Projektteil. Vormittags führen die Teams ihr Walking Skeleton in der gemeinsamen Umgebung vor, und jede:r reflektiert den Grundlagenteil nach Leitfragen (Ende von Phase 3). Nachmittags beginnt der Projektteil: Wie arbeitet ein Team mit einem Agenten wie Claude Code so, dass der Code zur Architektur passt? Architekturregeln als Prüfungen in der Pipeline, und was ein Mensch vor dem Merge liest. Danach gemeinsames Coding.
Thu 10.12.2026, 10:00 - 16:00: Eventual Consistency und Robustheit
Moderiert von: Lehrende. Was passiert mit Daten, die mehrere Services brauchen, und was tut ein Service, wenn Kafka oder ein Nachbar fehlt? Kurzer Input, danach gemeinsames Coding und Integration.
Thu 17.12.2026, 10:00 - 16:00: Integrationstag
Moderiert von: Lehrende. Wir bringen das Restaurant-System als Ganzes in der gemeinsamen Umgebung zum Laufen und sehen, wo die Services noch nicht zusammenpassen. Was dabei offen bleibt, ist die Arbeit bis zur Abschlussvorführung am 07.01.2027.
Workshops "Phase 5: Microservice Dungeon"
Thu 07.01.2027, 10:00 - 16:00: Abschluss der Restaurant-Fallstudie und Kickoff Microservice Dungeon
Moderiert von: Lehrende. Der Termin ist noch zu besprechen: statt Donnerstag 07.01. möglicherweise Dienstag 05.01. oder Mittwoch 06.01.2027, in derselben Woche. Dieser Tag in der Blockwoche gehört zu beiden Phasen: Vormittags führen wir das Restaurant-System als Ganzes vor und schließen die Fallstudie ab (Ende von Phase 4). Nachmittags Spielidee, Architektur und Core-Services des Dungeon, lokale Entwicklungsumgebung, und der Start in die Entwicklung der Player.
Ziel des Tages
Die Restaurant-Fallstudie ist abgeschlossen, und Sie wissen, wie Ihr Player starten soll.
Thu 21.01.2027, 10:00 - 16:00: Fortgeschrittene DevOps- und Hosting-Konzepte, Infrastructure as Code
Moderiert von: Lehrende. Geplant, Inhalte noch nicht festgelegt. Wie beschreibt man die Infrastruktur eines Systems als Code, und was ändert sich beim Hosting, wenn aus einer gemeinsamen Umgebung eine echte Produktion wird? Die Themen gelten für Ihren Player genauso wie für das Restaurant-System.
Thu 04.02.2027, 10:00 - 16:00: Monitoring mit Prometheus und Grafana
Moderiert von: Lehrende. Geplant, Inhalte noch nicht festgelegt. Logs und Metriken aus einem verteilten System einsammeln und sichtbar machen, mit Prometheus und Grafana, am Beispiel Ihres Players im Dungeon.
Thu 18.02.2027, 10:00 - 16:00: Abschluss-Codefight und Reflexion
Moderiert von: Lehrende. Der letzte Codefight läuft, während wir auf das Semester zurückschauen: Ist dieser Architekturstil etwas für Sie, und unter welchen Bedingungen würden Sie ihn wählen oder gerade nicht?
Praktikums-Meilensteine
Das Praktikum gliedert sich in die folgenden Meilensteine. Alle Meilensteine müssen bestanden sein, um das Gesamtpraktikum zu bestehen. Die Tests eines Meilensteins müssen komplett grün sein, um ihn zu bestehen. Eine Teilnahme an einem Meilenstein ist nur möglich, wenn alle vorigen Meilensteine bestanden wurden.
walking-skeleton: Das Walking Skeleton läuft
Grundlagenteil, Abschluss. Die AsyncAPI-Contracts der Teams werden zum Event-Katalog des Systems, und wir legen fest, wie die Services gebaut und betrieben werden. Am Ende läuft ein Walking Skeleton, in dem jeder Service mindestens ein Event über die gemeinsame Umgebung austauscht, und jede:r reflektiert den Grundlagenteil. Die Phase endet am Vormittag des 26.11.2026, dem Tag, an dem der Projektteil beginnt.
Der Meilenstein wird
komplett manuell überprüft.
Bitte beachten Sie, dass wir
nur ein (Zwischen-)Feedback
vor der Abgabe garantieren können. Nutzen Sie also die Workshops, um Fragen zu stellen und Ihre Lösung(en) zu diskutieren.
integration: Das Restaurant-System läuft zusammen
Projektteil. Die Teams bauen ihre Services aus und betreiben sie von Anfang an in der gemeinsamen Umgebung. Die Workshops verbinden jeweils einen Input mit Co-Located Coding, und jeder endet mit einer Integration.
Der Meilenstein wird
komplett manuell überprüft.
Bitte beachten Sie, dass wir
nur ein (Zwischen-)Feedback
vor der Abgabe garantieren können. Nutzen Sie also die Workshops, um Fragen zu stellen und Ihre Lösung(en) zu diskutieren.