An introduction to EventStorming technique and its implication in software development

1. Event Storming
PROCESS, STICKES & EVENTS
Francesco Garavaglia
01/2016

2. Agenda  The problem
 The solution: Event storming
 Summary

3. 3
The Problem
The Problem
0
0,2
0,4
0,6
0,8
1
1,2
1,00 2,00 3,00 4,00 5,00 6,00 7,00 8,00 9,00 10,00
Complexity
Time elapsed
Changing Cost
Green Field illusion
Maintainence
I cannot do this
Refactoring from
scratch

4. How to gather
requirements from
many different
departments/speci
alists?
4
Department C
Department E
Department A
Department D
Department B

5. Sequential data
gathering?
Time

6. 6
Or design by committee?
The Problem

7. 7
Event Storming
 Event Storming is a fun way of bringing developers and business experts together and drive your
analysis from the outside and quickly explore complex business domains in hours instead of
days/weeks.
Event Storming (or Model storming) is a way of
starting your analysis from the outside and quickly
explore complex business domains.
Invented by Alberto Brandolini
See
http://ziobrando.blogspot.dk/2013/11/introducing-
event-storming.html
The Problem

8. Much
requirements
gathering still
follow in the steps
of structural or
classic OO design
WE WRITE USE CASES/STORIES
AND AFTERWARDS LOOK
FOR NOUNS AND VERBS
8

9. 9
Usually we start with a simple model
The Problem

10. 10
And as time goes by…
The Problem

11. 11
It gets more complicated
The Problem

12. 12
And finally we drown
The Problem

13. We end up with
One Domain Model
to Rule them All
CAN’T WE AVOID
CEREMONIAL MODELING?
SOMETHING EASIER, FASTER
AND BETTER?
13

14. 14
Event Storming
 All togher into the same room
 Unlimited modelling surface
 Invite the right People
 Those who bring the questions
 Those who know the answers (not all of them)
 Value is in the interaction between people: miss one and you’ll miss n-1 interactions
 Refine the model step-by-step
The Solution: ES

15. 15
Hack the space
 There is no perfect room for a event storming
 Hacking the space is up to you
 Unlimited modelling space: can’t tell a problem size before exploring it
 Table creates the wrong phisical space
 position are fixed, no emerging alliances
 posture is far from optimal
 too easy to switch on laptops or other distractions
 No body language to observe
The Solution: ES

16. 16
Needed stuff
The Solution: ES

17. 17
How to run EventStorming session
 Explore the domain starting from Domain/Business
 Simple semantic and notation
 Represent the state transitions
 Gives us precision
 Easy to grasp by everybody in the room
 Place them along a timeline to visualize the process
 An event might be the predecessor or the follower of another one
The Solution: ES

18. 18
An Event message is non-prescriptive of what should happen in other services. It leaves this open to the
recipients, so that they themselves determine what to do based on occurrence of the event.
Events always carry a name in its past-tense form: OrderWasAccepted, OrderHasShipped,
CustomerWasReimbursed
Other qualities
 Immutable, i.e. content cannot be changed
 Always carries the ID of the Business Object it relates to
 An event can and will typically will be published to multiple consumers.
 The publisher of the event does not know who the recipients are
 And it doesn’t know what the recipients intend to do with the event
“An Event describes something that HAS happened”
What is an Event?
The Solution: ES

19. 19
 User Action model it as a Command
 External system
 Time
 Other Domain Events
 Documents
External
Time
Command Role
Event Event
Document
What does it cause Domain Events?
The Solution: ES

20. 20
Define a language…
A physical model provides a safe
support for spotting critical areas in
your business process
It’s not like
that
The Solution: ES

21. 21
..Along the time line
Enforce narratives: People like telling Stories, not just filling diagrams or template
 Encourage experts to tell a story
 Look for concrete examples
 look for edge cases, they fit perfectly in a narrative and they should fit into your model too
 Eventually turn them into tests
The Solution: ES

22. 22
Or reverse narrative
 Use Time line in a reverse mode:
What was the
path that led us
here?
What needs to
happen before,
so that this event
can happen
too?
The Solution: ES

23. 23
A Command message is prescriptive of what should happen. This is a stronger form of coupling than Event and Document
messages.
A Command’s primary goal is to capture USER INTENT
A Command supports a single usecase and targets a single Business Object
Commands always carry a name in its imperative form: CreateOrder, ShipOrder, CancelOrder, ReimburseCustomer, etc.
Other qualities
 Immutable, i.e. content cannot be changed
 Always carries the ID of the Business Object that it relates to
 A command can only be handled by ONE service
 The Operations that consume Commands don’t return values – but can throw exceptions
 Commands mutate Business Object state which results in one or more Events being published
“A command describes a Task that you want someone else to carry out for you and the recipient can
reject the Command”
Events are often the side effect of Commands
The Solution: ES

24. 24
Commands & Events
Receives a
Command
Asynchronousl
y
Publishes multiple
Events
asynchronously
The Solution: ES

25. 25
Entering the process manager
Process managers are the home of reactive behaviour in the systems «Whanaver» is the most
common word here
 Whenever we receive an
invoice we schedule a
payment
 Whenever we receive a Bs.we
try to reconcile it
Suppler
invoice
receiver
Bank
Statement
Received
Schedule
Payment
Reconcile
Operation
The Solution: ES

26. 26
Using Business Events to drive Business Processes
Sales Service
Shipping
Billing
Sales
Customers
MessageChannel
Online Ordering System
Web Shop
(Composite UI)
Billing Service
Shipping Service
Order
Accepted
Event
AcceptOrde
r
Command
The sales
fulfillment
processing
can now
begin…
The Solution: ES

27. 27
Not all the results are visible
 The model on the paper roll is huge and tangible but more value is created along the way
Event
Storming
More often than not, old
problems find a solution
during the workshop
The Solution: ES

28. 28
Not all the results are visible
 Conflicts and potential overlappings are highlighted
 Can finally see the Big Picture
 Conversations can finally Happen
 And ideas are popping out
The Solution: ES

29. 29
 Explore Aggregates Outside In
 An Aggregate receives Commands and decides to execute them or reject
them
 If the Aggregate executes a Command it will produce one or more Domain
Events as a result
Exploring…..
The Solution: ES

30. 30
Invoice
InvoiceLine
*
Account *
What:
• Cluster coherent Entities and Value
Objects, with complex associations into
Aggregates with well defined boundaries.
• Choose one entity to be root and control
access to objects inside the boundary
through the root.
• External objects hold references to the
root
• Aggregates only refer to other aggregates
by identity (their id)
Motivation:
Control invariants and consistency through the aggregate root.
Enables: Loading schemes, coarse grained locking and…
Ensuring consistency & transactional boundaries for Distributed scenarios
Root
….Aggregates
The Solution: ES

31. 31
 Explore Sub domains
 Different areas of responsibility map pretty well to different subdomains or
portions of the pork
 Explore Bounded Contexts
 During the discussion, some conflict areas with regards to different
interpretations of terms might emerge
 Draw boundaries between the multiple consistent models that will coexist in
your domain
31
… And sub-domains
The Solution: ES

32. 32
Conceptual CQRS
Users decide actions
according to the real world
experience (things they know
which are not in the system)
and read Model
Humans decide according
to different sets of info (ex:
faces, pictures, surnames,
ecc)
The model of anything: CQRS
The Solution: ES

33. 33
Summary: Event Storming
 Legend:
 User Action modeled as a Command
 External system
 Time
 Domain Events
 Documents
 IT Operations (Gateway)
 Aggregate
 Read Model
External
Time
Comma
nd
Role
Event Event
Docume
nt
IT Ops
Read
Model
Aggregate
Summary

34. 34
Event Storming is
 Powerful
 come up with a comprehensive model of a complete business flow in hours instead of weeks.
 Engaging:
 bring people with the questions and people who know the answer in the same room and to build a
model together
 Efficient
 the resulting model is perfectly aligned with Event Sourcing and EDA, and allows for a quick
determination of Bounded Context and Aggregate boundaries and thereby also Service boundaries
 Easy
 the notation is ultra-simple. No complex UML
 Fun
 Eventstorming workshops and fun, people are energized and deliver more than they expected. The right
questions arise, and the atmosphere is the right one.
Summary

35. Thanks
FRANCESCO.GARAVAGLIA@GMAIL.COM