WASP1: Microservices und Event-getriebene Architektur (MEA), SS25
“Microservices und Event-getriebene Architekturen” ist eine Wahlspezialisierung 1 (WASP1, 15 ECTS) im 6. Semester des Informatik Bachelor an der TH Köln. Studierende werden umfassend in die Konzeption, Entwicklung und Betrieb moderner verteilter Software-Architekturen eingeführt. Der Fokus liegt auf der praktischen Umsetzung von Microservices, einer Architektur, die komplexe Anwendungen als Sammlung kleiner, unabhängiger Dienste strukturiert. Die Studierenden lernen, wie diese Dienste vorrangig asynchron (d.h. über Events) effizient kommunizieren, und wie sich eine solche event-getriebene Architektur auf die praktische Entwicklung auswirkt.
- Studiengang und Modulbeschreibung
-
Informatik Bachelor
- Zeitraum und zeitliche Organisation der Veranstaltung
-
03.04.2025 - 31.07.2025. Organisiert als Ganztages-Workshops (i.d.R. Donnerstags 10:00 - 17:00). Genaue Daten und Inhalte stehen weiter unten. Gehen Sie davon aus, dass Sie regelmäßig ca. 2,5 Tage die Woche für die Veranstaltung reservieren.
- 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).
-
-
Raum:
0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch
detaillierte Wegbeschreibung
-
Videokonferenz-Link:
https://th-koeln.zoom-x.de/j/69442061500?pwd=1iwID1kbWZOqgca1nWZeZ7YNy7UVA9.1
(nur in Ausnahmefällen und wenn explizit vorher für den Tag kommuniziert)
-
Anmeldung
zur Veranstaltung
-
Bitte werden Sie Mitglied
in diesem ILIAS/ILU-Kurs.
Die Deadline ist 03.04.2025.
- Maximale / minimale Teilnehmerzahl
-
Die maximale Teilnehmerzahl ist
10.
Bei mehr Aufnahmeanträgen kann es ein Auswahlverfahren
(durch ein kurzes, informelles Bewerbungsvideo, siehe unten)
geben.
Deadline für die Einreichung ist der
07.04.2025.
Bei weniger als
5
Teilnehmer*innen kann die Veranstaltung leider nicht stattfinden.
- Miro Board für Inhaltsimpulse, Notizen und Modellieren während des Kurses
-
Im Kurs können Sie
dieses Board nutzen.
- 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 "Microservices und Event-getriebene Architekturen" konzentriert sich auf die praktische Anwendung von Kenntnissen zur Entwicklung und zum Betrieb moderner, verteilter Software-Architekturen. Wir verwenden aktuelle Technologien und Werkzeuge, die in der Entwicklung von Microservices Anwendung finden, um das Thema relevant und praxisnah zu behandeln.
Als Software-Entwickler:in kann ich Microservices mit Event-getriebenen Architektur entwerfen, implementieren und betreiben,
indem ich ...
- asynchrone Kommunikationsmuster in einer event-getriebenen Architektur entwerfe und implementiere,
- Spring Modulith als Framework für Event-getriebene Architekturen zur Umsetzung einer Softwarelösung einsetze,
- die Prinzipien und Best Practices von Microservices verstehe und anwende,
- einen Player-Service in der Umgebung "The Microservice Dungeon" entwickele, der Roboterschwärme steuert,
- meine Entwicklungserfahrung reflektiere, um Best Practices und Architekturprinzipien für zukünftige Projekte abzuleite,
damit ich komplexe und skalierbare Microservice-basierte Softwaresysteme entwickeln und betreiben kann.
Aufteilung der Veranstaltung
Die Wahlspezialisierung “Microservices und Event-getriebene Architekturen” (MEA) ist eine 15 ECTS-Wahlspezialisierung
im 6. Semester des Informatik-Bachelors an der TH Köln. Die Veranstaltung besteht aus zwei Teilen: einem Praxisteil (10 ECTS) und
einem Grundlagenteil (5 ECTS). Es gibt unabhängige Teilnoten für beide Veranstaltungsteile. Beide Teile sind eng miteinander verzahnt und bauen
aufeinander auf. Sie können nicht einzeln belegt werden.
Die Veranstaltung hat insgesamt 15 ECTS. Planen Sie daher bitte einen Aufwand von ca. 2,5 Tagen Vollzeit pro Woche ein.
Grundlagenteil (Event-getriebene Architektur mit Spring Modulith)
In der fachlichen Grundlagenveranstaltung (5 ECTS) als Bestandteil des WASP1 “Microservices und Event-getriebene Architektur”
bauen wir noch keine Microservices, sondern schauen auf eine Vorstufe davon - den
sogenannten Modulithen. In einem
Modulithen (Kunstwort aus “Module” und “Monolith”) sind die einzelnen Module wie bei Microservices streng von einander
entkoppelt, werden aber als Monolith in einem einzigen Repo verwaltet, gebaut und deployed. Man spart sich also den
Aufwand, für jeden einzelnen Service eine eigene CI/CD-Pipeline und eine eigene Deployment-Infrastruktur zu bauen.
Mit dieser Vereinfachung setzen wir uns im Grundlagenteil mit Event-getriebene Architektur auseinander - eine ganz
andere Art zu programmieren und “Programmabläufe zu denken”, verglichen mit den synchronen Aufrufen, die Sie z.B.
in ST2 kennengelernt haben. Als Framework nutzen wir
dabei Spring Modulith.
Diese Beschäftigung wird ganz praktisch verlaufen. Sie bekommen eine Programmieraufgabe in zwei Meilensteinen,
so ähnlich wie Sie das aus ST2 kennen. Der erste Meilenstein M0 enthält
nichts inhaltlich Neues, wird nicht benotet (muss einfach gemacht werden), und dient nur als “Baseline” für
die Migration zu einer Event-getriebene Architektur.
Hier ist ein Domänenmodell (fachliches DM) als Orientierung, das wir im Kickoff-Workshop miteinander
erarbeitet haben. Um allgemein zu bleiben, sind die Entities auf Deutsch - Sie nehmen natürlich die englischen
Begriffe aus “Ihrer” Individualisierung.
Im zweiten Meilenstein M1 machen Sie dann die Migration Ihrer Codebasis aus M0 nach Spring
Modulith. Wir begleiten diesen Prozess anhand von einigen Workshops, in denen wir Aspekte dieser Architektur,
Fallstricke, Stärken und Schwächen besprechen. Diese Phase von MEA dauert bis ca. Mitte Mai.
Teilnote für den Grundlagenteil
Die Noten in diesem Modul werden aus Teilaspekten ermittelt. Diese Aspekte mit ihren Gewichtungen sind
nachfolgend transparent dargestellt. Ich bewerte alle Aspekte mit einer Punktzahl zwischen 0 und 3
(Halb- oder Viertelpunkte möglich). Daraus ergibt sich dann wie dargestellt eine Gesamtnote.
Meilenstein M0 wird nicht bewertet - er muss einfach absolviert werden, sonst gilt der Grundlagenteil
als nicht bestanden. Die Notenaspekte für den Grundlagenteil spiegeln die erfolgreiche Migration
in Richtung Event-getriebene Architektur und Spring Modulith wider (Meilensteil M1).
Daneben erwarte ich eine aktive Teilnahme an
der Veranstaltung, weil es auch um Diskussion und Reflektion geht. Wir sollten über diesen Programmieransatz
sprechen! Sie müssen ihn nicht mögen, aber Sie sollten am Ende ein fundiertes Bild haben. Der Grundlagenteil
endet mit einem Abschluss-Workshop, in dem Sie Ihre Erfahrungen reflektieren.
Auch das fließt in die Benotung ein.
| Notenbestandteil |
Gewicht |
0 Punkte |
1 Punkt |
2 Punkte |
3 Punkte |
| Qualität und Umfang der Migration zu Event-getriebener Architektur in Spring Modulith (M1&M2) |
4 |
Es ist so gut wie nichts, oder nichts Sinnvolles, entstanden. |
Der Code compiliert. Er wurde aber mit deutlich unterdurchschnittlichem Aufwand ohne große Anpassungen an Event-getriebene Architektur nach Spring Modulith migriert. Ein großer Teil der Modulith- und EDA-spezifischen Tests sind rot. |
Der Code compiliert. Er wurde zum größten Teil in Event-getriebene Architektur in Spring Modulith migriert. Der überwiegende Teil der Modulith- und EDA-spezifischen Tests sind grün. |
Die Migration zu Event-getriebener Architektur in Spring Modulith war vollständig erfolgreich. Alle Tests sind grün, es wurden keine “Abkürzungen” genommen, die ggfs. Tests umgehen. |
| Reflektion nach Leitfragen |
1 |
Die Kernaspekte der Leitfragen sind nicht adäquat adressiert. Ein roter Faden ist nicht erkennbar. Eine Begründung fehlt weitgehend, oder ist unverständlich. |
Nur die wichtigsten Aspekte der Leitfragen sind adressiert. Trotz Inkonsistenzen, Auslassungen und Widersprüche ist ein roten Faden noch erkennbar. Einige Aspekte sind so gerade noch verständlich und nachvollziehbar begründet. |
Die Bearbeitung der Leitfragen ist meist konsistent. Viele wichtige Aspekte der Fragestellung sind adressiert. Es gibt Inkonsistenzen, Auslassungen und Widersprüche, im Ganzen ist es aber stimmig. Zumindest die Kernaspekte sind meist verständlich und nachvollziehbar begründet. |
Die Leitfragen sind in sich konsistent, vollständige und umfassend beantwortet. Alle Aspekte sind kurz, aber verständlich und nachvollziehbar begründet. |
| Beteiligung an fachlichen Diskussionen und Interaktionen im Gesamtprojekt |
1 |
Der/die Studierende hat sich so gut wie nicht an Interaktionen im Gesamt-Projektteam beteiligt. |
Der/die Studierende war unterdurchschnittlich und nur bei wenigen Anlässen an Interaktionen im Gesamt-Projektteam beteiligt. |
Der/die Studierende war durchschnittlich stark im Gesamt-Projekt sichtbar (Anleitung anderer, Hilfestellungen, Beiträgen zu fachlichen Diskussionen etc). |
Der/die Studierende ist außergewöhnlich stark im Gesamt-Projekt sichtbar gewesen, durch Anleitung anderer, Hilfestellungen, Beiträgen zu fachlichen Diskussionen und ähnlichem. |
Insgesamt sind max. 18 Punkte zu erreichen. Eine 1,0 gibt es ab 16,5 Punkten, eine 4,0 ab 6 Punkten. Notenstufen dazwischen werden entsprechend interpoliert. 0 Punkte bei ‘Qualität und Umfang der Migration zu Event-getriebener Architektur in Spring Modulith (M1)’ führen automatisch zu einer 5,0. Meilenstein M0 muss bestanden werden (d.h. alle Tests grün), sonst gilt der gesamte Grundlagenteil als nicht bestanden.
Zusammenarbeit ist gewollt, simples Copy-Paste ist ein Täuschungsversuch
Auch wenn es bei einem WPF, das man aus intrinsischem Interesse am Thema belegt, hoffentlich unnötig ist:
Hier sind die Regeln für das Bearbeiten der Programmieraufgaben aus M0 und M1.
Jede*r muss eine eigenständige Bearbeitung der Praktikumsaufgabe durchführen. Diskutieren Sie Ihre Lösungen - aber ein
einfaches Copy-Paste von Lösungen (unter Anpassung der Personalisierung) werte ich als Täuschungsversuch.
Praxisteil (Player-Implementierung im Microservice Dungeon)
Im Praxisteil (10 ECTS) entwickeln Sie im der Umgebung The Microservice Dungeon
einen Player-Service, der Roboterschwärme steuert, und bekommen so einen Einblick in die Besonderheiten dieser Architektur.
Auf der obigen Dokumentationsseite gibt es einen Getting Started Guide,
wo man z.B. nachlesen kann, wie man einen der bestehenden Templates (die sogenannten “Player-Skeletons”, verfügbar in 4 Programmiersprachen) nutzt,
oder wie man die lokale Entwicklungsumgebung aufsetzt.
Beim Kickoff des Praxisteils werde ich eine Einführung in The Microservice Dungeon geben, mit Geschichte,
Architektur, Roadmap, Infrastruktur, etc. Die Arbeit am Praxisteil beginnt ab ca. Mitte/Ende Mai bis Ende des Semesters.
Vieles an Arbeit findet “offline” statt, also nicht in den Workshops. Erfahrungsgemäß ist Discord für
die Kommunikation untereinander und mit den Dungeon-“Supervisors” sehr hilfreich. Dabei schreibt jede*r von Ihnen
einen eigenen Player-Service (aber natürlich ist Austausch untereinander ausdrücklich erwünscht). Bei den Workshops
machen wir jeweils einen Codefight, bei dem die Player gegeneinander antreten.
Teilnote für den Praxisteil - Playerentwicklung
Für die Entwicklung des eigenen Players erfolgt die Benotung auch wieder nach dem oben schon erklärten “0…3 Punkte”-Schema.
Wie schon im Grundlagenteil gibt es am Ende eine Reflektion nach Leitfragen, aber auch mit Demo des eigenen Players. Daneben
fließt auch das individuelle Engagement, die “Extra-Meile”, in die Note ein (sowohl was die Interaktion innerhalb der
Veranstaltung angeht, wie auch besondere Features im eigenen Code).
| Kriterium |
Gewicht |
0 Punkte |
1 Punkt |
2 Punkte |
3 Punkte |
| Features, die der Player beherrscht |
5 |
Player ist nicht lauffähig, und/oder es gibt keine sinnvollen und demofähigen Aktivitäten des Players, die über die zugelieferte Codebasis hinausgehen. |
Es gibt sinnvolle Aktivitäten des Players, die über die zugelieferte Codebasis hinausgehen. |
Ein Teil der wesentlichen Spiel-Features sind implementiert. Kaum Exceptions. |
Viele wesentlichen Spiel-Features implementiert. Keine Exceptions auf der Console. |
| Bewertung der Softwarequalität |
2 |
Die Architektur des Players zeigt kein wirkliches Verständnis verteilter, asynchron kommunizierender Anwendungen. Die Grundlagen guten Software-Designs aus Clean Code und Application Design scheinen nach Durchsicht der Software nicht beherrscht. Selbst elementare Regeln und Prinzipien werden nicht eingehalten. |
Die Architektur des Players zeigt nur elementares Verständnis verteilter, asynchron kommunizierender Anwendungen, und ist teilweise inkonsistent. Die Grundlagen guten Software-Designs aus Clean Code und Application Design scheinen nach Durchsicht der Software nur ansatzweise beherrscht. Regeln und Prinzipien werden nur manchmal eingehalten. |
Die Architektur des Players zeigt ein zufriedenstellendes Verständnis verteilter, asynchron kommunizierender Anwendungen, und ist weitgehend konsistent. Die Grundlagen guten Software-Designs aus Clean Code und Application Design scheinen nach Durchsicht der Software weitgehend beherrscht. Regeln und Prinzipien werden meist eingehalten. |
Die Architektur des Players zeigt ein volles Verständnis verteilter, asynchron kommunizierender Anwendungen, und ist durchgehend konsistent. Die Grundlagen guten Software-Designs aus Clean Code und Application Design scheinen nach Durchsicht der Software voll beherrscht. Regeln und Prinzipien werden vollständig eingehalten. |
| Weitergehende Leistungen |
2 |
Keine über das geforderte Maß hinausgehenden Leistungen. |
Überdurchschnittliches Engagement in einem Bereich (besondere Features, ein UI-Client, umfassende Unit-Tests, außergewöhnlicher individueller Einsatz im eigenen Team oder der gesamten Gruppe, z.B. durch Helfen, etc.) |
Deutlich mehr als gefordert in einem Bereich, oder überdurchschnittliches Engagement in mehreren Bereichen (besondere Features, ein UI-Client, umfassende Unit-Tests, außergewöhnlicher individueller Einsatz im eigenen Team oder der gesamten Gruppe, z.B. durch Helfen, etc.) |
Deutlich mehr als gefordert in mehreren Bereichen (besondere Features, ein UI-Client, umfassende Unit-Tests, außergewöhnlicher individueller Einsatz im eigenen Team oder der gesamten Gruppe, z.B. durch Helfen, etc.) |
| Deployment und Codefight |
1 |
Kein Deployment in die Produktivumgebung. |
Erste Maßnahmen fürs Deployment umgesetzt. |
Deployed in die Produktivumgebung, aber mit Problemen. Teilnahme am Codefight nicht vollständig möglich. |
Deployment in die Produktivumgebung. Erfolgreiche Teilnahme am Codefight. |
| Präsentation (Demo & Reflektionsfragen) |
1 |
Die Kernaspekte der Leitfragen sind nicht adäquat adressiert. Ein roter Faden ist nicht erkennbar. Eine Begründung fehlt weitgehend, oder ist unverständlich. |
Nur die wichtigsten Aspekte der Leitfragen sind adressiert. Trotz Inkonsistenzen, Auslassungen und Widersprüche ist ein roten Faden noch erkennbar. Einige Aspekte sind so gerade noch verständlich und nachvollziehbar begründet. |
Die Bearbeitung der Leitfragen ist meist konsistent. Viele wichtige Aspekte der Fragestellung sind adressiert. Es gibt Inkonsistenzen, Auslassungen und Widersprüche, im Ganzen ist es aber stimmig. Zumindest die Kernaspekte sind meist verständlich und nachvollziehbar begründet. |
Die Leitfragen sind in sich konsistent, vollständige und umfassend beantwortet. Alle Aspekte sind kurz, aber verständlich und nachvollziehbar begründet. |
| Beteiligung an fachlichen Diskussionen und Interaktionen im Gesamtprojekt |
1 |
Der/die Studierende hat sich so gut wie nicht an Interaktionen im Gesamt-Projektteam beteiligt. |
Der/die Studierende war unterdurchschnittlich und nur bei wenigen Anlässen an Interaktionen im Gesamt-Projektteam beteiligt. |
Der/die Studierende war durchschnittlich stark im Gesamt-Projekt sichtbar (Anleitung anderer, Hilfestellungen, Beiträgen zu fachlichen Diskussionen etc). |
Der/die Studierende ist außergewöhnlich stark im Gesamt-Projekt sichtbar gewesen, durch Anleitung anderer, Hilfestellungen, Beiträgen zu fachlichen Diskussionen und ähnlichem. |
Damit sind inklusive weitergehender Leistungen insgesamt max. 36 Punkte erreichbar. Zum Bestehen (4,0) genügen 12 Punkte, eine 1,0 gibt es ab 33 Punkte. Bei ‘Bewertung der Softwarequalität’ muss genügend Code-Menge für eine Bewertung mit mehr als 1 Punkt vorhanden sein. 0 Punkte bei ‘Features, die der Player beherrscht’ führt zum Nicht-Bestehen des Praxisteils.
Checkliste für den eigenen Player
Damit es am Schluss beim Code-Review der Player kein böses Erwachen gibt, hier eine Checkliste für den eigenen Player.
- Features, die der Player beherrscht
- Player ist lauffähig, ohne dauernde Exceptions auf der Console?
- Viele wesentlichen Spiel-Features implementiert?
- Softwarequalität
- Clean-Code-Regeln eingehalten?
- SOLID-Prinzipien und DDD-Konventionen respektiert?
- DDD: Module fachlich geschnitten?
- SRP: keine Gott-Klassen und -Module?
- DIP: keine zyklischen Abhängigkeiten?
- Sinnvolle Architekturlösungen im Detail? (Z.B. parallele Eventverarbeitung, Idempotenz der Eventverarbeitung, “intelligente” Persistenzlösungen, etc.,
die dann auch dokumentiert sind)
- Automatisiertes Testing
- Sinnvollen Satz von reinen Unit-Tests vorhanden (nur Klassen- / POJO-Ebene, keine Mocks nötig)?
- Integrations-Tests (brauchen lauffähige lokale Umgebung oder - noch besser - Mocks)
- E2E-Tests mit Hilfe von Matias Testszenarien Framework?
- Testabdeckung des Codes zufriedenstellend?
- Alle Tests sind grün?
- Sinnvolles Logging?
- Dokumentation
- Dokumentation der Funktionalität vorhanden in der README.md?
- Welche Commands werden unterstützt?
- Was sind die Grundgedanken der Strategie?
- Wie bildet man die Map ab?
- Wie weist man den Robotern die Aufgaben zu?
- …
- Besonderheiten der Architektur dokumentiert?
- Javadoc für zentrale Klassen und Methoden?
- Deployment
- Dockerfile vorhanden?
- Helmchart vorhanden und ok?
- Deployment in die Produktivumgebung erfolgreich?
Workshops "Grundlagenteil"
Thu 03.04.2025, 10:00 - 15:00: Kickoff
Wir starten mit einer Einführung in die Veranstaltung und die Rahmenbedingungen. Außerdem gibt es eine inhaltliche Einführung. Danach geht es direkt mit der Teambildung und dem Aufsetzen Ihrer Umgebung los.
Ort des Workshops
Raum:
0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch
detaillierte Wegbeschreibung.
Ziel des Tages
Sie kennen die Rahmenbedingungen für MEA und können beginnen.
Die nachfolgenden Videos bieten zusätzliche Informationen zum Thema
Agenda
-
10:00 - 11:30:
Warmup und Motivation
- Wie groß sind eigentlich große Software-Systeme?
- Wie organisiert man die Arbeit an so großen Systemen?
- Monolithen vs. Microservices
- Was ist ein Microservice? Welche Vor- und Nachteile hat dieser Stil?
- Modulithen als Kompromiss
- Hier sind die Folien zum Warmup zum Nachlesen
-
11:30 - 12:15:
Organisatorisches
- Zeitplan und Struktur des Grundlagen- und des Praxisteils
- Youtube-Channel
- Discord als präferiertes Kommunikationsforum
- Benotung
-
12:15 - 13:15:
Mittagspause
-
13:15 - 14:45:
Fallstudie "Travel Management System"
- Erarbeitung logisches Datenmodell
- Was ist zu beachten?
-
14:45 - 15:00:
Wrap-Up und Fragen
- Abschließend Wrap-Up und Ende des Workshop-Tages
Aufgabe bis zum nächsten Workshop
Nach dem Workshop bearbeiten Sie bitte
Meilenstein M0.
Thu 10.04.2025, 14:00 - 18:00: Migration zu Spring Modulith und Event-getriebener Architektur
Ich stelle Ihnen drei grundsätzliche Ansätze vor, wie man die Kommunikation zwischen Bestandteilen seiner Software (in DDD-Begriffen "zwischen seinen Aggregates", bei Modulith "zwischen seinen Modulen" und bei Microservices "zwischen seinen Services") organisieren kann. Aufbauend auf den Erfahrungen, die Sie in der einleitenden Programmieraufgabe gemacht haben, ordnen Sie Ihren eigenen Stil ein. Anschließend besprechen wir die Aufgabe, dass Sie Ihren eigenen Code in Richtung einer Event-getriebenen Architektur migrieren. Dafür verwenden wir Spring Modulith, das ich Ihnen kurz vorstelle.
Ort des Workshops
Raum:
0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch
detaillierte Wegbeschreibung.
Ziel des Tages
Sie können mit der Migration Richtung Event-getriebenen Architektur beginnen.
Agenda
-
14:00 - 15:30:
Drei grundsätzliche Ansätze für Modulkommunikation
- Ich stelle Ihnen drei grundsätzliche Ansätze für die Kommunikation zwischen Modulen vor
- Sie ordnen Ihren eigenen Code dort ein
-
15:30 - 17:00:
Kurze Einführung in Spring Modulith
-
17:00 - 17:45:
Einführung in die neue Aufgabe (M1) für den Rest des Grundlagenteils
- Vorstellung der Aufgabe
- Starthilfe, so dass jede*r ein in der IDE lauffähiges Repo hat und selbst weiterprogrammieren kann
- Wissensquellen
-
17:45 - 17:00:
Wrap-Up und Fragen
- Abschließend Wrap-Up und Ende des Workshop-Tages
Aufgabe bis zum nächsten Workshop
Nach dem Workshop bearbeiten Sie bitte
Meilenstein M1.
Thu 24.04.2025, 10:00 - 14:00: Zwischenstand und Fragen
Wir klären den Zwischenstand und die praktischen Probleme, die bei Design und Implementierung auftreten. Es gibt eine Vertiefung zum Thema "SAGA-Pattern".
Ort des Workshops
Raum:
0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch
detaillierte Wegbeschreibung.
Ziel des Tages
Ihre Fragen bezüglich der Implementierung sind geklärt, Sie haben keine "Blocker".
Agenda
-
10:00 - 10:45:
Rundlauf - Stand der Dinge, Hürden, Unverständliches, Eindrücke
- Rundlauf über alle Teilnehmer zum Stand der Dinge
- Diskussion offener Fragen direkt oder als Schwerpunktthema anschließend
-
10:45 - 11:15:
Vergleich der (Abhängigkeits-)Komponentendiagramme
- Die 4 "grünen" Lösungen (plus meine eigene Beispiellösung) sind teils ähnlich, teils nicht
- ... das stellen wir mal nebeneinander
-
11:15 - 12:00:
Fehlschlagende Vorgänge und das SAGA-Pattern
- Eine kleine Erweiterung unseres Systems - was ist, wenn eine Reisebuchung nicht umgesetzt werden kann?
- Vergleich synchron - asynchron
- SAGA-Pattern (Kompensationsoperationen)
- Ausblick auf neuen Meilenstein M2
-
12:00 - 13:00:
Mittagspause
-
13:00 - 14:00:
Weiterführende Diskussionen (Puffer)
- Puffer für weiterführende Diskussionen
- (wenn nicht notwendig, dann enden wir früher)
Aufgabe bis zum nächsten Workshop
Nach dem Workshop bearbeiten Sie bitte
Meilenstein M2.
Thu 08.05.2025, 10:00 - 17:00: Praxisberatung
Ein weiteres Treffen zum Zwischenstand und zum Klären von Fragen. Je nachdem auch mit inhaltlichem Schwerpunkt.
Ort des Workshops
Raum:
0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch
detaillierte Wegbeschreibung.
Ziel des Tages
Ihre Fragen bezüglich der Implementierung sind geklärt, Sie haben keine "Blocker".
Agenda
-
10:00 - 17:00:
(... detaillierte Agenda folgt ...)
Thu 22.05.2025, 14:00 - 18:00: Abschluss des Grundlagenteils
Zum Abschluss des Grundlagenteils schauen wir zurück auf Ihre Erfahrungen mit der Umsetzung des Event-getriebenen Ansatzes in Spring Modulith. Anhand von vorgebenen Leitfragen reflektiert jede*r von Ihnen die gemachten Erfahrungen Anschließend folgt der Kickoff für den zweiten Teil von MEA, den Praxisteil. Dort implementieren Sie selbst einen Microservice - einen Player-Service für den Microservice Dungeon. Ich stelle Ihnen das Konzept und mögliche Startpunkte vor.
Ort des Workshops
Raum:
0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch
detaillierte Wegbeschreibung.
Ziel des Tages
Sie haben sich mit den Erfahrungen des Grundlagenteils auseinandergesetzt und sind bereit, den Praxisteil zu beginnen.
Agenda
-
14:00 - 16:00:
Reflektion und Retrospektive
- Rückschau auf die eigenen Erfahrungen anhand vorgebener Leitfragen
- Jede*r fasst ca. 10 min die eigenen Erfahrungen zusammen
-
16:00 - 18:00:
Start in den Praxisteil mit dem "Microservice Dungeon"
- Vorstellung des Microservice Dungeon
- Startpunkt für die Entwicklung
Workshops "Praxisteil"
Thu 05.06.2025, 10:00 - 17:00: Unterschiede zwischen MSD und einer typischen eCommerce-Microservice-Landschaft, aktueller Stand und Codefight
Was sind die Unterschiede zwischen der existierenden Dungeon-Architektur und einer Microservice-Landschaft z.B. für eCommerce, wie man sie in der Praxis findet? Ich gehe zusätzlich auf unsere Umbaupläne im MSD 2.0 ein, um deutlicher zu machen, wo die Gemeinsamkeiten und wo die Unterschiede liegen. Dann besprechen wir den aktuellen Stand der Player-Entwicklung. Abschließend machen wir einen Codefight, um zu schauen, wo jede*r steht.
Ort des Workshops
Raum:
0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch
detaillierte Wegbeschreibung.
Ziel des Tages
Sie können besser einordnen, was Sie da gerade tun, und haben keine Blocker.
Agenda
-
10:00 - 17:00:
(... detaillierte Agenda folgt ...)
Thu 03.07.2025, 10:00 - 17:00: Aktueller Stand und Codefight
Wir besprechen den aktuellen Stand der Player-Entwicklung. Ggfs. wird ein aktuelles Thema als Schwerpunkt betrachtet. Abschließend machen wir einen Codefight, um zu schauen, wo jede*r steht.
Ort des Workshops
Raum:
0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch
detaillierte Wegbeschreibung.
Ziel des Tages
Entwicklung geht voran, keine Blocker.
Agenda
-
10:00 - 17:00:
(... detaillierte Agenda folgt ...)
Thu 24.07.2025, 10:00 - 13:00: Abschluss und Codefight
Am Schluss des Praxisteils machen wir eine Abschlussreflektion nach Leitfragen (ähnlich wie im Grundlagenteil). Abschließend machen wir einen Codefight, um zu schauen, wo jede*r steht.
Ort des Workshops
Raum:
0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch
detaillierte Wegbeschreibung.
Ziel des Tages
Sie haben den Praxisteil erfolgreich abgeschlossen.
Agenda
-
10:00 - 13:00:
(... detaillierte Agenda folgt ...)
Thu 31.07.2025, 10:00 - 17:00: Blocker-Tag, wenn mehr Zeit nötig ist
Nur ein Blocker / Platzhalter, falls der Praxisteil sich länger als geplant hinziehen sollte.
Thu 04.09.2025, 10:00 - 17:00: Blocker-Tag, wenn mehr Zeit nötig ist
Nur ein Blocker / Platzhalter, falls der Praxisteil sich länger als geplant hinziehen sollte.
Meilensteine im Grundlagenteil
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.
M0: Initiale Implementierung des "Simple Travel Management Systems", ohne Vorgaben
In diesem Meilenstein implementieren Sie (erstmal ohne weitere Vorgaben) eine Aufgabenstellung gegen vorgegebene Unit Tests. Die ist dann unsere "Baseline", um daraus eine Event-getriebene Architektur mit Spring Modulith zu machen.
Der Meilenstein wird
komplett automatisch (per Unit-Tests) überprüft.
-
Ausgabe: Thu 03.04.2025,
15:00
-
Abgabe bis spätestens:
Thu 10.04.2025,
09:00
M1: Migration zu Spring Modulith und Event-getriebener Architektur
In diesem Meilenstein (der den Rest des Grundlagenteils umfasst) implementieren Sie migrieren Sie Ihren Code zu Spring Modulith und einer rein Event-basierten Kommunikation zwischen den Aggregates.
Der Meilenstein wird
komplett automatisch (per Unit-Tests) überprüft.
-
Ausgabe: Thu 10.04.2025,
15:00
-
Abgabe bis spätestens:
Thu 01.05.2025,
09:00
M2: Fehlschlagende Operationen und SAGA-Pattern
Sie erweitern Ihr System um Kompensationsoperationen für fehlschlagende Reise-Buchungen.
Der Meilenstein wird
komplett automatisch (per Unit-Tests) überprüft.
-
Ausgabe: Thu 01.05.2025,
15:00
-
Abgabe bis spätestens:
Thu 22.05.2025,
09:00
Bildquellen
