SlideShare ist ein Scribd-Unternehmen logo
1 von 35
Downloaden Sie, um offline zu lesen
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 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 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 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 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 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 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 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
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 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 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 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 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 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
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 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 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 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 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 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
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
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 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 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 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
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 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 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 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
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
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…
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
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
Danke!
Fragen?
foodbot@devboost.com

Weitere ähnliche Inhalte

DevDay_Mirko Seifert.pdf

  • 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
  • 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