Using EventStorming to drill into domain modelling complexity: from the big picture into the design of aggregates, processes and read models. A different approach to enterprise software modelling.

1. DDD EUROPE PRESENTS…

2. A @ZIOBRANDO
PRODUCTION

4. IN THE LAST
EPISODES…

5. NOBODY TALKS
ABOUT THEIR DOMAIN

6. WHO CAN BE
THAT STUPID?

7. ABOUT ME
• Started coding in 1982
• Entered DDD in 2005
• Met Eric
• Started Avanscoperta
• Met Greg
• Event-Based Modelling in 2012
• Blast during Vaughn’s tour
• EventStorming in 2013
• Started EventStormers community
• 348 members (on Google+)

8. SOFTWARE
DEVELOPMENT IS A
LEARNING PROCESS

9. WORKING CODE
IS A SIDE EFFECT

10. I USE
INSTEAD

11. INVITE THE
RIGHT PEOPLE
PEOPLE WITH QUESTIONS
PEOPLE WITH ANSWERS
A FACILITATOR

12. PROVIDE AN UNLIMITED
MODELLING SURFACE
“
AND BE PREPARED TO EXPAND IT

13. MODEL WITH DOMAIN
EVENTS ALONG A TIMELINE
“

14. REALLY SIMPLE

15. THEN IT GROWS…

16. (EXTERNAL SYSTEMS, IN PINK)
AND GROWS…

17. (HOTSPOTS, IN PURPLE)
AND GROWS…

18. THE GOAL(S) OF A
BIG PICTURE
EVENTSTORMING

19. 1.
ARE WE SOLVING THE
RIGHT PROBLEM?

20. ARE WE SOLVING THE RIGHT PROBLEM?
CALL IT “CORE”, CALL IT “BOTTLENECK”…
… PEOPLE WILL “TELL” YOU WHAT THE REAL PROBLEM IS
AND PLEASE READ “THE GOAL” IF YOU HAVEN’T

21. DOES IT MATTER?

22. WHERE DETAILS ARE MAKING A DIFFERENCE…
IN THE CORE DOMAIN…
• Creative
• Always looking for alternatives
• Continuously refining solutions
• Perfectionist

23. IN A FIXED-BUDGET NON-CRITICAL PART OF THE DOMAIN
SOMEWHERE ELSE
• Creative
• Always looking for alternatives
• Continuously refining solutions
• Perfectionist
TROUBLEMAKER

24. 2.
CAN WE SUCCEED?

25. MAKING THE RISK OBSERVABLE
EXTERNAL SYSTEMS & HOTSPOTS
PEOPLE AND POLITICS

26. IS MY WALKING
SKELETON

27. NOT EVERY BATTLE IS WORTH FIGHTING
OUTCOMES
• We’re on a problem worth solving:
• let’s prototype a solution right now!!
• Ouch! …the real problem is somewhere else.
• Fine, let’s use the money more wisely.
• Ouch! …they can’t even agree on the problem…
• Shake hands, smile, and leave quietly.

28. LET’S ASSUME
WE’RE LUCKY

29. OUR BACKLOG

30. • The involved Domain Experts
• The Development Team (including UX)
• a Facilitator
• Unlimited Modelling Space
• Unlimited Surface
• Unlimited Supply of markers, stickies and so on
• We’ll have only to take care of our limited Energy.
OUR TEAM

31. TECHNICAL TRAININGS
OUR SAMPLE DOMAIN
• My Company —> We have a real domain expert here…
• Public & Private Training and workshops, (plus coaching
&mentoring).

32. HOW DID WE GET THERE?

33. MORE GUESSING
THAN EXPLANATION

34. IT’S A LEARNING
PROCESS!

35. SKIP THE BORING
PARTS
IF THERE’S TIME: THE REAL REASON WHY I AM NOT A PIANO PLAYER!

36. DONEC QUIS NUNC

39. LET’S TRY AGAIN!

40. A TICKET!

41. AND THE CORRESPONDING COMMANDS

42. ANY CANDIDATE NAMES…

43. WHAT IF SOMEBODY
DOESN’T SHOW UP?

44. ANYTHING ELSE?

47. GETTING THERE…

49. • Can we transfer it?
• Good question. In fact this never happen
with individual purchases, they usually ask for
a refund, or if they can reuse the ticket with a
different edition of the same training class.
• What can happen instead is companies,
buying a group ticket, asking to switch
people, or delaying actual participant names
till he very last moment.

50. • Can we transfer it?
• Good question. In fact this never happens
with individual purchases, they usually ask for
a refund, or if they can reuse the ticket with a
different edition of the same training class.
• What can happen instead is companies,
buying a group ticket, asking to switch
people, or delaying actual participant names
till he very last moment.

51. I LOVE THIS
MESS!
CAPTURE IT!
ALL OF IT.
YES, EVEN IF IT MEANS A LOT MORE STICKY NOTES

52. ADD MORE
SPACE!

53. — Anonymous
WHAT IF TICKET IS AN ABSTRACT
CLASS? WITH INDIVIDUAL AND GROUP
TICKET AS SEPARATE SUBCLASSES
”
“

55. … WE INVITED THE
RIGHT PEOPLE!

56. • There’s no need for any automatic operation.
It only happened once. Doing it manually
(whatever that means) is fine.

57. • Talking with the right people, we
might get the answers we like.
• The complexity is in the domain,
it’s just not necessarily worth
implementing.

58. 1. MAKE IT VISIBLE
2. SAFELY IGNORE IT

59. — Anonymous Developer
WHAT ABOUT PRIVATE
CLASSES? AREN’T THEY THE
SAME THING
”
“

60. THINKING ABOUT DATA…
Headline
Description
Duration
Trainer
City
Date
Venue
Headline
Description
Duration
Trainer
PRIVATE PUBLIC

61. THINKING ABOUT BEHAVIOUR…
Scheduled
Base Price defined
Sales Opened
Confirmed
Cancelled
Sold out
Delivered
Replanned
Planned
Signed off
Scheduled
Delivered
PRIVATE PUBLIC
NOT ALIKE

62. TWO INDEPENDENT
PROCESSES IN
SALES
BASICALLY THE
SAME PROCESS,
IN CONTENT
DEFINITION

64. MAYBE THEY DO BELONG SOMEWHERE…
WHAT ABOUT SEATS

65. EXPLORING THE RELATIONSHIP

66. THERE’S SOMETHING MISSING

67. POLICY IS A GOOD NAME FOR IT
BUT YOU CAN FIND ALSO “PROCESS” OR “THE WHENEVER BOX”

68. DO WE REALLY NEED THAT?
LET’S ASK THE DOMAIN EXPERT
• Aren’t they the same thing?
• Not at all. We need to add the trainer to the participants. Room
capacity and coffee breaks plus lunch are based on the total
number of people in the class.
• Moreover: the trainer might bring a co-trainer, the company can
have an internal person in the class, or there can be “guests”
that are not passing through the ticketing system.
• We’re currently creating “fake tickets” for everybody in order
to have all participants in the same container, but one single
mistake and everything fall apart.

69. (ET VOILÀ)
INDEPENDENT MODELS!
TRAINERS DON’T NEED TO
BUY A TICKET
EVERYONE IN THE TRAINING
ROOM DESERVES SOME
GOOD COFFEE, AND A
GOOD LUNCH

70. — Ziobrando
IN A RESTAURANT, IF YOU’RE
THE TRAINER, YOU GET EXACTLY
THE SAME FOOD
”
“

71. ISN’T THAT TOO COMPLEX?

72. MORE PRECISELY

73. DO WE HAVE TO
IMPLEMENT IT?
BOUNDED CONTEXTS ARE HEAVY… ?

74. IT DEPENDS…

75. UNDERSTANDING THE
PROBLEM MUST BE CHEAP

76. A PROPER
IMPLEMENTATION IS
VALUE VS COST

77. ARE WE IN THE
CORE?

78. NO. THE REAL PROBLEM IS…
DAMN, WE WERE JUST WANDERING…

79. (A) REAL PROBLEM
• We were stuck in go/no-go decisions
• Collaborators didn’t know whether to cancel or confirm the class
• I needed to explain my decision making process.

80. “WHAT IS THE DATA
NEEDED IN ORDER TO
TAKE THIS DECISION?”

82. THIS IS SCARY
HOW MANY AGGREGATES SHOULD I QUERY?

84. ENTER READ MODELS

85. SO MANY WAYS
HOW CAN WE IMPLEMENT IT?
• Projections
• Composite UIs (including mashups)
• Denormalisation
• Good old queries (not forbidden, just
uncool)

86. WE MOVED THE
BOTTLENECK!!

87. NOW, THE REAL PROBLEM IS…

88. WE DON’T SELL ENOUGH
• Some training class are good, but not appealing
• Users don’t take the BUY TICKET decision.

89. “WHAT IS THE DATA
NEEDED IN ORDER TO
TAKE THIS DECISION?”

90. NOT THAT
SIMPLE…

91. THIS IS A PIZZA. IT IS
FOOD, THAT PROVIDES
THE CALORIES AND THE
ENERGY YOU NEED IN
ORDER TO SURVIVE TILL
THE NEXT MEAL. IT IS
AVAILABLE IN SEVERAL
SIZES AND TOPPINGS.
CONTACT US IF YOU
WANT TO KNOW MORE.

92. Order now!
Feeling hungry?

93. IT’S NOT ONLY
THE DATA…

94. USERS AREN’T
ONLY RATIONAL
DID ANYONE NOTICE THAT I MENTION THE UX PEOPLE?

95. AND IT’S NOT
THE SAME DATA

96. HIS OWN MONEY,
KNOWS THE STUFF.
COMPANY MONEY.
NEEDS PERMISSION.
COMPANY MONEY.
CALENDAR IS IMPORTANT.
NEED SAFETY AND
DISCOUNTS.

97. OUCH!
WHY CAN’T ANYTHING JUST BE SIMPLE?

98. CHOOSE A TARGET, AND
RUN AN EXPERIMENT.

99. IT’S ABOUT THE
QUESTIONS, NOT THE
NOTATION

100. WE’RE MODELLING A
FLOW OF DECISIONS

101. WE’LL HAVE
TONS OF IDEAS

102. NOT ALL OF THEM
WORTH PURSUING

103. MOSTLY UX
DRIVEN
EXPLORATION
MAKING SENSE OF DATA, FROM
TRIVIAL TO BI, TO BIG DATA
TRADITIONAL SOFTWARE
ARCHITECT’S REALM
THANKS TO GREG’S SQUIRREL ;-)

104. THE GOAL IS NOT TO
WRITE COOL SOFTWARE

105. THE GOAL IS TO SOLVE
THE RIGHT PROBLEM
IMPACT MAPPING - NO ESTIMATES - USER STORY MAPPING

106. KEEP THE
MODELS SIMPLE

107. CAN’T ACHIEVE
SIMPLICITY WITHOUT
DIVING INTO CHAOS

108. KEEP THE
PROBLEMS SIMPLE

109. MODELLING THE FLOW
WITHIN THE SPACE CONSTRAINTS
THIS IS THE ACCIDENTAL SELF-INFLICTED COMPLEXITY NOBODY WILL PAY YOU FOR

110. THANK YOU!

111. WANT TO KNOW MORE?
• Really fresh: www.eventstorming.com
• LeanPub book in progress:
• http://leanpub.com/
introducing_eventstorming
• Blog: http://ziobrando.blogspot.com
• Twitter: @ziobrando
• Trainings & Workshop facilitation:
• http://www.avanscoperta.it