Jede Firma, die Software entwickelt, kämpft mit hoher Komplexität, technischen Schulden, unklaren Anforderungen und zu geringer Entwicklungsgeschwindigkeit - Punkt. Wer etwas anderes behauptet, lügt das blaue vom Himmel herunter. Events können alle diese Probleme aus der Welt schaffen. Als Events verstehen wir Ereignisse in Geschäftsprozessen, z.B. "jemand hat eine Pizza Hawaii ohne Ananas bestellt". Sie sind ein einfaches Konzept, welches Domänenexperten benutzen können, um komplexe Szenarien zu analysieren. Gleichzeitig sind Events ein technisches Mittel bei Softwaredesign und Implementierung. In unserer Session zeigen wir Euch, wie man Events bei den typischen Aufgaben in der Softwareentwicklung (Anforderungsanalyse, Architektur, Implementierung, Test und Deployment) einsetzen kann. Wir stellen Euch die Methoden "Event Storming" und "Event Modeling" vor und diskutieren, wie ein solches Vorgehen mit Domain-driven Design zusammenpasst. Darauf aufbauend zeigen wir an konkreten Beispielen, welche technischen Möglichkeiten es gibt, Event-basierte Architekturen zu realisieren, z.B. als klassischer Monolith, mit Hilfe von Microservices oder auch mit Serverless Functions. Zuletzt stellen wir typische Herausforderungen vor, die solche Architekturen mit sich bringen. In unserem Talk lernt Ihr wie man fachliche Anforderungen und deren technische Umsetzung durch die Nutzung eines gemeinsamen Konzepts miteinander integriert. Ihr erfahrt wie die o.g. Probleme dadurch adressiert werden - und welche neuen Probleme ihr Euch dafür einhandelt.

1. Sandra,
das Essen ist fertig.
Events - Die Lösung für alle Deine Probleme!?
D E V D A Y | 2 0 2 2

3. 3 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
- Ausgangspunkt – Was ist eigentlich unser Problem?
- Motivation - Warum Events?
- Events everywhere
- Anforderungsanalyse
- Architektur
- Technologiestacks
Agenda

4. 4 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
- Kein Mensch blickt mehr durch
- Alles dauert zu lange
- Der existierende Code ist ein Klotz am Bein
- Niemand weiß was eigentlich wirklich genau gebaut werden soll
- Die Performance der Anwendung war auch schon mal besser
- Eigentlich müsste man das nochmal komplett neu schreiben
- Wir können nicht einfach horizontal skalieren
Was ist eigentlich unser Problem?

5. 5 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
- Geschäftsereignisse, d.h. Dinge, die in der (realen) Welt passieren bzw. passiert sind
- Beispiele:
- Ich habe eine Yogamatte bestellt
- Ich habe meine Online-Banking App auf dem Smartphone geöffnet
- Mein Notebook Akku ist leer
- Der Drucker hat kein Gelb mehr
- Meine Frau hat mir eine Nachricht geschickt
- Das Bier ist alle
Wir beschränken uns hier nicht auf Nachrichten im Messaging Queues!
Was sind Events?

6. 6 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
1. Events sind ein einfaches, verständliches Konzept – auch für Nicht-Entwickler
2. Alle (Geschäfts-)Prozesse bestehen aus einer Folge von Events
3. Events sind ein Konzept, das in verschiedenen/allen Phasen der Softwareentwicklung nützlich ist
4. Events sind nachhaltig
Google, AWS, Azure (und die anderen Großen) machen auch Events.
Kann also nicht so schlecht sein - oder?
Motivation - Warum Events?

7. 7 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
FoodBotTM – Was ist das?
- Software zur (hochautomatisierten) Versorgung von Entwicklern mit Nahrungsmitteln in der
Pandemie (während der Arbeitszeit)
Nichtfunktionale Anforderungen
- Skaliert für Millionen von Nutzern
- Plattform Modell
- Marktplatz Modell
- Muss Weltherrschaft möglich machen
- Alles muss irgendwie mit Events gemacht werden
Kontext: Wir sind CTO im FoodBotTM Startup

8. 8 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Frage:
1. Was soll FoodBotTM eigentlich machen?
2. Was passiert eigentlich im Kontext von Entwicklern, Nahrung und Arbeit?
Antwort:
- Event Storming!
Anforderungsanalyse im FoodBotTM Startup – Mit Events!

9. 9 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
1. Alle Stakeholder in einen Raum bringen
2. Post-its und Stifte verteilen
3. Jeder schreibt auf, welche Ereignisse in der Anwendungsdomäne vorkommen
4. Regeln:
- Formulierung im Präteritum
- Es gibt keine falschen Events
- Duplikate sind erlaubt
5. Grobe Sortierung auf einem Zeitstrahl
Event Storming - Vorgehen
Ideen für Events?

10. 10
someone suggested a venue
to go to
User signed up
User declined their automatic
meal choice.
Lunch has been ordered
Nice Location to eat outside
was found.
Food has been delivered
Today's menu was
presented.
Food was ordered.
User accepted their
automatic meal choice.
the clock has hit the usual
lunch time
Someone asked if it is time
for lunch.
A group was formed that
want to go for lunch.
New lunch location was
added to the system
User deleted their account
User wanted to see the menu
of a location.
Restaurant closed
permanently
Food got ready to eat
New meal for a location
was added to the system
Dish was served.
Restaurant closed due to
private event
Ordered food was payed.
User chose preferred
restaurant
User selected an automatic
meal choice for a location.
Lunch was paid by a single
person
someones device has entered
the office WiFi
The menu of a restaurant
changed
Some got hungry
Food was delivered to the
office
someones device has left the
office WiFi
A wrong meal was delivered
A new restaurant was found
someone paid a meal for
someone else
Users voted for the type of
food
venue was closed before
picking up food
Person A payed for Person B
who has forgot his wallet.
User changed taste
User chose a meal for today
that's not their automatic
choice.
Based on chosen food type,
the location was found on
delivery app
User suggested a restaurant
Payment for order failed Restaurant closed
Pickup-Team was
assembled
The order was completed
an order was sent to the
delivery service
User suggested a restaurant.
Prices have changed
Order has been sent to
restaurant
Prices have changed
User did not answer in time
a food delivery arrived at the
office
User left office before
delivery arrived
Preferred meal went
unavailable
A second or third restaurant
was proposed for the day.
Preferred meal turned out to
be unavailable
Person A payed for all
delivered dishes.
Delivery did not arrive in time
A menu was added to a
location.
Payment was received
Dish was selected
Payment was outstanding
for (more than) one day
Delivery did arrive in time
The money for payment was
collected by one user from all
users
Payment was not received in
time
Group left the office to find
a nice place to eat.
Restaurant accepted the
order
Order turned out to be
incomplete
Various persons paid
fractions of the bill
Selected meal not available
in the restaurant
The Pickup-Team picked up
the food
Person A checked menu of
different places online.
Restaurant denied the order
a food delivery service shut
down
Selected meal is unavailable
Lunch arrived back in the
office
User scheduled vacation
Order turned out to be
erroneous
Pickup-Team was not able
to pickup food
the menu of a delivery service
was updated
Preferred meal was added
someone suggested a food
delivery service to order from
User announced Dönerstag
shortly after midnight
A user payed the paying
colleague in cash.
The delivery was delayed
because of traffic jam or any
other reason
User confirmed the
proposed meal
A user payed the paying
colleague via PayPal.
User didn't like the food -
refund!
User selected a meal other
than the proposed one
User asked for some more
variation of the food choices
a venue has been chosen for
lunch
A user ordered the food.
Restaurant could not accept
order due to high demand
The food choices were
automatically ordered at
11.30/12.30
Delivery was postponed to a
later time
someone entered the office
someone left the office
The delivery guy was lost and
couldn't find the office
The Resque-Team found the
delivery guy and picked up
the food
The food was payed
The food was delivered to the
office
User changed (default)
payment method
User Management Meal Preferences Food pick up
Payment
The preferred selected meal
was removed from the menu
The preferred meal cost was
changed
Venue Management Location Selection
the preparation of the food
took longer then expected
Food Ordering
The user haven't paid yet
Vouchers are collected for
free meal
Meal selection
Customer Satisfaction
The special offer was
promoted for certain day
Eating
Food Delivery Presence
a new food delivery services
got available
a delivery service has been
choosen for lunch
The meetings after lunch
break was postponed
The app for food delivery
was chosen
Time Selection Eating at Venue
Food is ready to be picked up
The Resque-Team did not
manage to find the lost
delivery guy
E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Event Storming –Session (ca. 30min, 9 Teilnehmer)
Events!
112 Events
14 Gruppen

11. 11 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
- Verständnis für Domäne wird gemeinsam entwickelt
- Begriffe der Domäne werden geklärt (Synonyme, Semantik)
- Einfachkeit der Methode macht Beteiligung für alle möglich
- Man ist gezwungen konkret zu werden bzw. es ist erlaubt konkret zu sein
- Man findet Features
- Man findet Sonderfälle
Event Storming – Vorteile
A food delivery service
shut down
Payment was outstanding
for (more than) one day
A delivery guy
got hit by a meteor

12. 12 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Events, aber wie weiter?
Event Modeling (nach Adam Dymitruk):
- Timeline(s) – Anordnen der Events auf einer Zeitleiste
- Neue Konzepte:
- Commands
- Views (Read Models)
- External Systems
- Wireframes

13. 13 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Event Modeling (nach Adam Dymitruk)
Restaurant added
Add dish
Add opening hours
Restaurant list
Add restaurant
Opening hours modified Dish added
Add restaurant
Sülze To Go 3000
Add
Add restaurant
Fr 8:00 – 23:00
Add
Mo 8:00 – 22:00
Di 8:00 – 22:00
Mi 8:00 – 22:00
Do 8:00 – 23:00 Add restaurant
Sülze-Burger mit Alles
Add
Sülze To Go 3000
Command
Event
View
Wireframe
Timeline

14. 14 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Event Modeling (DevBoost Style)
Timeline(s) – Anordnen der Events auf einer Zeitleiste
- Um Verständnis zu vertiefen
- Um Lücken zu finden
- Danach verwerfen
Neue Konzepte:
- Actions
- Entitäten

15. 15 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Event Modeling (DevBoost Style)
It’s almost lunch time
(e.g., 11:30)
Food choices
were made
Compute automatic
food choices
Restaurant
Dish
Preference
Food choices
were made
Food choices were
published to users
Notify FoodBotTM users
User
Contact
User Location
Event Action Entity

16. 16
Was ist anders?
- Einfach
- Konkret
- Verständnisorientiert
- Kollaborativ
- Technologieunabhängig
- Kompatibel mit Stories, SCRUM etc.
Wir modellieren wie unsere Software auf die Welt reagiert –
statt Software zu definieren und zu hoffen, dass die Welt dazu passt.
E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Wrap-up - Anforderungsanalyse und Events
Alle wissen genau
was gebaut werden muss
Alle haben Überblick
über das Gesamtsystem

17. 17 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Architektur und Events
Architektur:
1. “… is the stuff that's hard to change”
2. “The structure of any system is isomorphic to the structure of the organization that designs it”
3. “determines the degree to which an existing software system is extensible”
4. …

18. 18 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Architektur – Stuff that‘s hard to change
Was ist schwer zu ändern?
- Programmiersprachen
- Frameworks
- Kommunikationsprotokolle
- Datenbanken

19. 19 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Architektur – Stuff that‘s hard to change
Warum ist es schwer zu ändern?
- Programmiersprachen – Eine pro Box - Zu große Boxen
- Frameworks – Eine „Alternative“ pro Box - Zu große Boxen
- Kommunikationsprotokolle – 1:n Kommunikation – Direkt gekoppelte Boxen
- Datenbanken – Zu viele Daten in einer Datenbank, Shared Databases - Zu große Boxen
Fazit: Boxen die zu groß oder zu stark gekoppelt sind, sind schwer zu ändern.

20. 20 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Große, gekoppelte Boxen
Was tun?
- Große Boxen: Klein machen
- Gekoppelte Boxen: Entkoppeln
Wie machen wir
kleine, entkoppelte Boxen?

21. 21 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Boxen - Teilen und Entkoppeln mit Events
Teilen
- Events sind „fachliche Interfaces“ zwischen Geschäftslogikbausteinen
- Events sind „natürliche Erweiterungspunkte“
Entkoppeln
- Events haben keine Intention (es ist etwas passiert vs. es soll etwas passieren)
- Events haben keine (festen) Adressaten
- Events werden veröffentlicht, nicht an jemanden gesendet

22. 22
FoodBotTM NotificationService
FoodBotTM Monolith
E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Boxen - Teilen
It’s almost lunch time
(e.g., 11:30)
Food choices
were made
Compute automatic
food choices
Food choices were
published to users
Notify FoodBotTM users
FoodBotTM FoodChoiceService
It’s almost lunch time
(e.g., 11:30)
Food choices
were made
Compute automatic
food choices
Food choices were
published to users
Notify FoodBotTM users
Event Action Deployment Unit

23. 23
FoodBotTM NotificationService
E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Boxen - Entkoppeln
FoodBotTM FoodChoiceService
It’s almost lunch time
(e.g., 11:30)
Food choices
were made
Compute automatic
food choices
Notify FoodBotTM users
FoodBotTM NotificationService
FoodBotTM FoodChoiceService
It’s almost lunch time
(e.g., 11:30)
Send
Notifications
Compute automatic
food choices
Notify FoodBotTM users
Publish “Food choices
were made“ event
Food choices
were made
Event
Publish/Subscribe
System
Event Action Deployment Unit

24. 24 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Architektur – Conway‘s law
- Kleine Teams – Kleine Boxen?
- Stabile Teams – Stabile Boxen?
Teams ändern sich, Boxen müssen das auch können.
Eine flexible Organisation braucht eine flexible Architektur.

25. 25 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Architektur – Conway‘s law
Was helfen uns Events hier?
- Events bilden “fachliche Sollbruchstellen” in der Architektur und damit zwischen den Teams
- Events lassen sich einfach zu Domänen (und damit zu Teams) gruppieren
- Events helfen dabei von technischen Teamaufteilungen (FE und BE Team) „Abstand zu halten“

26. 26 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Architektur – Erweiterbarkeit
Warum ist Erweiterbarkeit so schwierig?
- Wir sind keine Hellseher.
- Wir denken aber wir sind Hellseher.
Was helfen uns Events hier?
- Events beziehen sich auf die Vergangenheit – etwas das wir kennen.
- Events machen keine Annahmen über die Zukunft.

27. 27
Was ist anders?
- Fachliche, natürliche Teile
- Flexibilität und Erweiterung per Design
- Gleiche Konzepte wie bei Anforderungsanalyse
- Kompatibel mit Monolith, Modulith, MicroServices, Serverless
Wir teilen unsere Software an fachlichen Grenzen – statt an technischen.
Wir bereiten uns auf Veränderung vor – statt sie zu vermeiden.
E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Wrap-up – Architektur und Events
Existierender Code
hält uns nicht mehr auf
Neue Erweiterungen
sind schnell und einfach

28. 28 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Events Implementieren
Wie bauen wir das
möglichst kompliziert anspruchsvoll?

29. 29 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
In-process
- No framework: Simple Event Dispatcher (HashMap plus optionaler ThreadPool)
- Frameworks: Spring Events, Spring Async, Quarkus Async Events, Micronaut Application Events, .NET
Events, …
Cross-process
- Kafka, RabbitMQ, NATS
Cloud-native
- AWS MQ, SQS, EventBroker,
- Google PubSub
Events Implementieren

30. 30 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Wenn es so einfach ist, warum nicht überall machen?
- Entkopplung macht es schwerer den Kontrollfluss zu verstehen
- Async als Default kann schwierig sein
- Transaktionshandling basiert meist auf synchronem Code
- Transaktionen funktionieren nicht (einfach) über Prozessgrenzen hinweg
- Austausch von Events zwischen Prozessen bedingt Delivery Guarantees (at least once, at-most
once) – Transactional Outbox, Idempotente Funktionen etc.
Events Implementieren

31. 31
Was ist anders?
- Inversion of control
- Flexibilität bzgl. der Event-Kommunikation
- Gleiche Konzepte wie bei Anforderungsanalyse
Wir richten unsere Erweiterungspunkte nach der Fachlichkeit –
statt nach den Entwicklern.
E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Wrap-up – Implementierung und Events
Anwendung kann einfach
horizontal skalieren
“Neu schreiben” geht für
einzelne Teile

32. 33 E V E N T S - P R O B L E M E F Ü R A L L E D E I N E L Ö S U N G E N ?
Neue Probleme
- Asynchrone Kommunikation
- Eventual Consistency
- Unzuverlässige Kommunikation
- At least once, At most once
- Komplexität durch Verteilung
- Traceability
- Deployments
- Event Kompatibilität bzw. Versionierung
und noch mehr…

33. 34 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Zusammenfassung
- Denken „in Events“ verändert eure Sichtweise
- Events können der rote Faden in der Wertschöpfungskette sein
- Events sind nicht neu, aber heute als Konzept noch relevanter
- Events kann man mit Message Queues realisieren, muss man aber nicht
- Probleme bei Event-getriebenen Architekturen entstehen größtenteils durch die Verteilung – nicht
durch die Modellierung bzw. Nutzung von Events

34. 35 E V E N T S - D I E L Ö S U N G F Ü R A L L E D E I N E P R O B L E M E ! ?
Eventology - Auf einer Folie praktisch zusammengefasst
Ohne Eventology Mit Eventology
Du versucht die Zukunft vorherzusehen Du lebst im Moment
Du glaubst zu wissen was passieren wird Du weißt nur das was passiert ist
Du hast viel “Architektur” Du hast wenig “Architektur”
Du denkst in Commands Du denkst in Events
Du definierst Interfaces Du definierst Event Schemata
Du rätst was zukünftig noch gebraucht wird Du weißt was aktuell gebaucht wird und das ist ok
Du versuchst “wasserfallartig” zu planen Du reagierst agil auf neue Anforderungen
Du hast viele Probleme ohne Events Du hast viele andere Probleme mit Events

35. Danke!
Fragen?
foodbot@devboost.com