English version of the accompanying slide deck. But from now on I'll call it Event-Storming ;-)

1. 1giovedì 23 maggio 13

2. Goals
Quickly sketch a model for a complex
system
Have the basic concepts of Domain-
Driven Design emerge without
prerequirements.
2giovedì 23 maggio 13

3. 3giovedì 23 maggio 13

4. In practice...
Stick a paper roll on a wall.
We might have up to 25 metres of
modeling space
Collaborative work
4giovedì 23 maggio 13

5. Yes, I mean that much
space...
5giovedì 23 maggio 13

6. Domain Events
Might resemble an Activity Diagram
...but we’re not doing UML
Events cannot be discussed. They happened. Deal
with it.
System-wide view.
Every team start to imagine a domain, instead
of asking to the domain expert... :-(
Real system might be a lot simpler
Real system might be a lot more complex
6giovedì 23 maggio 13

7. Hint:
...it gets a lot more interesting if we
explore areas we don’t know.
... with the domain expert.
... with concrete examples.
7giovedì 23 maggio 13

8. 8giovedì 23 maggio 13

9. Event Origin
Events do not just appear out of the
blue:
some originate from user actions
some originate in external systems
some are generated by time
...some are originated as a response to other
events
9giovedì 23 maggio 13

10. 10giovedì 23 maggio 13

11. FLOW (team decided this way)
Team decided to start
from the right... we
called it WOLF instead
of FLOW then.
11giovedì 23 maggio 13

12. 12giovedì 23 maggio 13

13. Event Flow
Search for predecessors or
consequences of our events
Using verbs in the past helps clarify the
semantics:
“wedding” is not an event, it’s a process (don’t
tell it to your wife)
More actors are joining our system
13giovedì 23 maggio 13

14. 14giovedì 23 maggio 13

15. Aggregates
“How do I correctly define
aggregates?” ... yes, that’s THE
question
Have a look to DDD mailing lists, if you don’t
believe it
Our goal is to define aggregates outside
in
15giovedì 23 maggio 13

16. Definition
An aggregate represents consistency
unit: a group of classes changing state
together.
...but it’s not always clear enough...
...how big these objects are?
...how do they look like?
It has something to do with transactional
boundaries but ours might be wrong.
16giovedì 23 maggio 13

17. Rule of thumb
To sketch aggregate boundaries we can
think about
Informations deleted together
Informations moved together
Informations distributed together
...but that’s still a little too data-centric
17giovedì 23 maggio 13

18. Invariants
Forget data:
An aggregate can accept or reject a
command.
Upon which information?
What is always guaranteed for our
aggregate?
18giovedì 23 maggio 13

19. 19giovedì 23 maggio 13

20. Aggregates
Shifting the focus on invariants helps
aggregate modeling
Smaller, more controllable units
Variations are propagated via Domain Events
A better domain exploration
The whole is eventually consistent
20giovedì 23 maggio 13

21. Example
Max particpants per class:
Where does this constraint come from?
Classroom capacity? --> accept and look for a
better location (if there’s time available)
Class physiological limit --> stand-by and
waiting list or propose next edition
No accidental complexity requirements.
21giovedì 23 maggio 13

22. 22giovedì 23 maggio 13

23. Subdomains
Business level system partitioning
Some portions are core for our company
competitivity.
Es. things that are going to sell more.
Other are simply necessary, but no key
differentiators.
Es. invoicing: it’s needed but no customer will
choose us for the invoice layout. Good enough is
good enough.
23giovedì 23 maggio 13

24. Languages
In mid/large-sized companies we’ll have
many stakeholders.
Different goals
different backgrounds,
different languages
...will require different models
Caution: we aren’t talking about Bounded
Contexts...yet
24giovedì 23 maggio 13

25. 25giovedì 23 maggio 13

26. Bounded Contexts
Highlight the different models in play
Software components
Legacy components
Languages used
They’re a realistic snapshot, not the
image of our wishes...
26giovedì 23 maggio 13

27. 27giovedì 23 maggio 13

28. Users & Personas
Got a chance to include users and their
categories in the picture? Why not!?
We can highlight personas and make
them part of the model...
...especially if this triggers an
interesting conversation with the
domain experts.
28giovedì 23 maggio 13

29. 29giovedì 23 maggio 13

30. Tests
Some interesting details might emerge
during the conversation. Why not take a
note?
In natural language
...according to BDD lingo (--> Cucumber)
In an event driven perspective, the
structure Given [events] When
[command] Then [event] fits very well :-)
30giovedì 23 maggio 13

31. 31giovedì 23 maggio 13

32. Takeaways
Model of a complex enterprise system
ignoring data
... what if data model is part of the problem?
Tight focus on system behavior and not
on static data structure.
32giovedì 23 maggio 13

33. Takeaways
The model is created collectively in a
cooperative learning fashion and
provides a good high-level view.
Are you sure DEs know everything?
Time-boxed, but....
Space-boxed but....
33giovedì 23 maggio 13

34. Legacy Systems
The sketched model is close to an “ideal
system model”
It’s NOT the starting point to rewrite from scratch!
But it’s a good reference to establish a direction
Legacy components that do not belong in the
domain emerge like accidental complexity.
batch operations, legacy stuff feel really
inappropriate.
34giovedì 23 maggio 13

35. 35giovedì 23 maggio 13