Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Designing
Reactive Systems
with
Event Storming
DDD and Microservices
Great: Some Boundaries
Strategic - Bounded Contexts
Payments
Shipping
DDD and Microservices
Great: Some Boundaries
Tactical - Aggregates
Booking
DDD and Microservices
Not so great:
Too much focus on structure
Noun Obsession
Boundaries yes - but sometimes these are po...
DDD and Microservices
Better: Events First
„It is not the things that matter in early stages of design…
…it is the things ...
Microservices
DDDEventStorming
EventStorming
Start with Events Seat
selected
EventStorming
Only then - explore
what triggers these
events, add commands
Seat
selected
Choose
seat
EventStorming
Only then start
thinking about
aggregates.
Seat
selected
Choose
seat
Booking
EventStorming
Let aggregates emerge
- don’t jump to
conclusions.
Seat
selected
Choose
seat
Seat map
EventStorming
First publication - 2013?
Impression, not empirically backed:
Has quickly become very popular for
„big pictu...
EventStorming Challenge
Reactive Systems
The Supertrend in Microservices
Events vs. Messages
Message: Directed, has a recipient.
Event: Undirected, is emitted and picked up by interested
parties....
Microservices vs. Reactive Systems
Microservices are about isolation, speed of change, agility.
Reactive Systems are about...
Actors
Actor libraries & frameworks
Async HTTP Stack, REST/JSON support built-in
Persistence through 

Event Sourcing/
CQRS
Event
Event
Event
Command A A'
Each service can be
clustered.
Node A Node B
Node C
X
B
A
Z
X
Y
N
M
Kafka integrated as messaging backbone.
„Going to microservices is like going from Newton’s physics
to Einstein’s physics. Newton’s time marched forward
uniformly...
Event Storming to the Rescue!
+
Reactive Systems & Event Storming
Event Storming model elements map 1:1 to implementations e.g. in Lagom
Event -> Event
Co...
Reactive Systems & Event Storming
It goes so far that it’s actually encoded in types..
Aggregate
Command
Event
Event Storming for Reactive Microservices
Maybe you don’t see the beauty of it, let me quote the Blue Book again…
Summary
event storming is not only for „big picture“ analysis.
you can do event storming on different levels, including
mo...
Summary
The biggest obstacle for building truly reactive systems is not
technology, the tools are there (e.g. actors).
Ins...
Summary
A message driven, actor based implementation not only has
technical merit (as in being reactive), it’s also the
„n...
Experience it for yourself
Shameless Self Promotion: Workshops
https://jax.de/microservices/domain-driven-design-microserv...
Further Reading
http://www.russmiles.com/essais/going-events-first-for-microservices-
with-event-storming-and-ddd
http://z...
Event Storming, DDD, Reactive Systems, and Microservices
Upcoming SlideShare
Loading in …5
×

Event Storming, DDD, Reactive Systems, and Microservices

Talk from microxchg Berlin 2018 - http://microxchg.io/2018/index.html

  • Be the first to comment

Event Storming, DDD, Reactive Systems, and Microservices

  1. 1. Designing Reactive Systems with Event Storming
  2. 2. DDD and Microservices Great: Some Boundaries Strategic - Bounded Contexts Payments Shipping
  3. 3. DDD and Microservices Great: Some Boundaries Tactical - Aggregates Booking
  4. 4. DDD and Microservices Not so great: Too much focus on structure Noun Obsession Boundaries yes - but sometimes these are poorly chosen
  5. 5. DDD and Microservices Better: Events First „It is not the things that matter in early stages of design… …it is the things that happen.“  Russ Miles http://www.russmiles.com/essais/going-events-first-for-microservices-with-event-storming-and-ddd
  6. 6. Microservices DDDEventStorming
  7. 7. EventStorming Start with Events Seat selected
  8. 8. EventStorming Only then - explore what triggers these events, add commands Seat selected Choose seat
  9. 9. EventStorming Only then start thinking about aggregates. Seat selected Choose seat Booking
  10. 10. EventStorming Let aggregates emerge - don’t jump to conclusions. Seat selected Choose seat Seat map
  11. 11. EventStorming First publication - 2013? Impression, not empirically backed: Has quickly become very popular for „big picture“ analysis - not (yet) so much for modelling services.
  12. 12. EventStorming Challenge
  13. 13. Reactive Systems
  14. 14. The Supertrend in Microservices
  15. 15. Events vs. Messages Message: Directed, has a recipient. Event: Undirected, is emitted and picked up by interested parties. Not important for our discussion, please ignore.
  16. 16. Microservices vs. Reactive Systems Microservices are about isolation, speed of change, agility. Reactive Systems are about scalability, reliability. Microservices and Reactive Systems complement each other, the goal is to build Reactive Microservices.
  17. 17. Actors
  18. 18. Actor libraries & frameworks
  19. 19. Async HTTP Stack, REST/JSON support built-in
  20. 20. Persistence through 
 Event Sourcing/ CQRS Event Event Event Command A A'
  21. 21. Each service can be clustered. Node A Node B Node C X B A Z X Y N M
  22. 22. Kafka integrated as messaging backbone.
  23. 23. „Going to microservices is like going from Newton’s physics to Einstein’s physics. Newton’s time marched forward uniformly with instant knowledge at a distance. Before microservices, distributed computing strove to make many systems look like one with RPC, 2PC etc.. In Einstein’s universe, everything is relative to one’s perspective.“ Pat Helland
  24. 24. Event Storming to the Rescue! +
  25. 25. Reactive Systems & Event Storming Event Storming model elements map 1:1 to implementations e.g. in Lagom Event -> Event Command -> Command Aggregate -> Persistent Entity keeping the model and implementation aligned
  26. 26. Reactive Systems & Event Storming It goes so far that it’s actually encoded in types.. Aggregate Command Event
  27. 27. Event Storming for Reactive Microservices Maybe you don’t see the beauty of it, let me quote the Blue Book again…
  28. 28. Summary event storming is not only for „big picture“ analysis. you can do event storming on different levels, including modelling services.
  29. 29. Summary The biggest obstacle for building truly reactive systems is not technology, the tools are there (e.g. actors). Instead, the challenge is in the design, which requires you to embrace the asynchronous, distributed nature. Event Storming as a modelling tool can help to overcome this obstacle.
  30. 30. Summary A message driven, actor based implementation not only has technical merit (as in being reactive), it’s also the „natural“ implementation for an event storming model, if you want model and implementation to align closely.
  31. 31. Experience it for yourself Shameless Self Promotion: Workshops https://jax.de/microservices/domain-driven-design-microservices-workshop/ (Mainz, 23.4.2018) https://eu.scaladays.org/lect-6836-domain-driven-design-and- microservices.html (Berlin, 14./15.5.2018)
  32. 32. Further Reading http://www.russmiles.com/essais/going-events-first-for-microservices- with-event-storming-and-ddd http://ziobrando.blogspot.de/2013/11/introducing-event-storming.html https://leanpub.com/introducing_eventstorming https://www.lagomframework.com https://blog.redelastic.com/corporate-arts-crafts-modelling-reactive- systems-with-event-storming-73c6236f5dd7

×