1.
What lies
beneath
@ziobrando

2.
About me
Very hard to explain my job to my
mother
running www.avanscoperta.it
Modelling (almost) everything with
sticky notes, markers and a paper
roll.
Calling this stuff

3.
Quick recap of
Focusing on Big Picture only

4.
Big Picture Workshop
Invite the right people
Provide an unlimited modelling space
Surface, Markers, stickies
Start Modelling with Domain Events

5.
Environment setup

6.
Establish a timeline
Some facilitator tricks will
kickstart the discussion quickly

7.
Explore domain Events

8.
Capture Hotspots
You won’t have to ask for problems…
problems will find you!!

9.
Keep capturing hotspots…

10.
Outcome (big Picture):
The whole process visible
Massive learning
Critical areas highlighted

11.
More specifically…
No scope limitation (paper roll)
Exploration of boundaries (External
Systems & People)
-> The BOTTLENECK is in the picture.
-> The CORE DOMAIN is in the
picture

12.
EventStorming
blends lean and
Theory of
constraints into
Software
Development and
Domain-Driven
Design

13.
EventStorming
blends lean and
Theory of
constraints into
Software
Development and
Domain-Driven
Design

14.
EventStorming
blends lean and
Theory of
constraints into
Software
Development and
Domain-Driven
Design

15.
Quick recap of
Theory of
Constraints
Focusing on Bottleneck only

16.
Bottleneck
Main Constraint for a system
throughput

17.
Bottleneck strategies
focus on it >>> Subordinate
everything else
improve it relentlessly
small short term improvements will
make a difference
… while you work on long term
improvements too

18.
Can’t find
the heart…

19.
Can’t find
the heart…
yes, but look at
these nails…

20.
Improving
anything but the
bottleneck is
close to
meaningless
Unless you have enough firepower to
attack many problems at once..

21.
The realm of the foggy PO
We have plenty of items in the backlog…
…whose purpose is going to be clear someday

22.
What I’ll be
speaking about
and finally…

23.
In the last 2 years
Been EventStorming in many
different situations
Different domains
large companies & small
organisations
Established business and startups
…many different countries…
…for different reasons…

24.
Biases??
All the possible ones!
I’ve seen only scenarios where I was
invited…

25.
What does a
bottleneck look
like?

26.
Digging into the flow

27.
Unrolling it…
Business processes expose a
repeatable structure

28.
Let’s look deeper

29.
Let’s look deeper
Aggregate
Policy / Process
Domain Event
Command
External
System

30.
Let’s look deeper
Here is where the
system is making
decisions:
Aggregate
Policy / Process
Domain Event
Command
External
System

31.
Let’s look deeper
Here is where the
system is making
decisions:
Simple local decision
fit into Aggregates
Aggregate
Policy / Process
Domain Event
Command
External
System

32.
Let’s look deeper
Here is where the
system is making
decisions:
Simple local decision
fit into Aggregates
Aggregate
Policy / Process
Domain Event
Command
External
System

33.
Let’s look deeper
Here is where the
system is making
decisions:
Simple local decision
fit into Aggregates
More complex &
Reactive decision
making fits into
policies/Processes
Aggregate
Policy / Process
Domain Event
Command
External
System

34.
Let’s look deeper
Here is where the
system is making
decisions:
Simple local decision
fit into Aggregates
More complex &
Reactive decision
making fits into
policies/Processes
Aggregate
Policy / Process
Domain Event
Command
External
System

35.
Let’s look deeper
Here is where the
system is making
decisions:
Simple local decision
fit into Aggregates
More complex &
Reactive decision
making fits into
policies/Processes
Aggregate
Policy / Process
Domain Event
Command
External
System
#BusinessProcesses
#Transactions
#SWArchitecture

36.
Let’s look deeper
Command/
Decision
User/
Actor/
Persona/…
User
Interface

37.
Let’s look deeper
Here is where the
USER is making
decisions:
Command/
Decision
User/
Actor/
Persona/…
User
Interface

38.
Let’s look deeper
Here is where the
USER is making
decisions:
…which are based
upon real world
experience, and the
information available
on the screen
Command/
Decision
User/
Actor/
Persona/…
User
Interface

39.
Let’s look deeper
Here is where the
USER is making
decisions:
…which are based
upon real world
experience, and the
information available
on the screen
Command/
Decision
User/
Actor/
Persona/…
User
Interface
#UX
#FrontEndDevelopment
#UIDesign

40.
Let’s look deeper
Domain
Event
Read Model
User
Interface

41.
Let’s look deeper
Domain
Event
Read Model
User
Interface
Here is were we
transform raw data
into readable
meaningful
information

42.
Let’s look deeper
Domain
Event
Read Model
User
Interface
Here is were we
transform raw data
into readable
meaningful
information
#BusinessIntelligence
#Readability

43.
And the winner is…

44.
And the winner is…
Most of the
bottlenecks
are here!

45.
Most of the
bottlenecks
are here!
And the winner is…

46.
Most of the
bottlenecks
are here!
And the winner is…

47.
But we’re
observing the
effect, not the
cause

48.
Annoying anti-
patterns in Legacy
code

49.
The Big Ball of Mud

50.
Recurring anti-pattern

51.
“That’s our key class”

52.
“That’s our key class”
Big class with overloaded responsibility in the disputed land
between 2 (or more) Bounded Contexts

53.
Everybody agrees
what an order is?

54.
Everybody agrees
what an order is?
Of course we do!

55.
Everybody agrees
what an order is?
Of course we do!
An order is an
order!

56.
Everybody agrees
what an order is?
Of course we do!
An order is an
order!
And has a
customer
too!

57.
Everybody agrees
what an order is?
Of course we do!
An order is an
order!
And has a
customer
too! Agreed!

58.
Perfect recipe:
Talk with many people
Model Data-First (everybody agrees
on nouns)
Add some “Dogmatic DRY principle”
Repeat

59.
The Big Ball of Mud

60.
The Big Ball of Mud
I swear it was a
monolith last time I
checked!!!

61.
The solution

62.
The solution
A Draft Model with
loose integrity
constraints

63.
The solution
A Draft Model with
loose integrity
constraints
Constraints
implemented as
warnings

64.
The solution
A Draft Model with
loose integrity
constraints
Constraints
implemented as
warnings
A Validation barrier (constraints
implemented as blockers)

65.
The solution
A Draft Model with
loose integrity
constraints
Constraints
implemented as
warnings
A Validation barrier (constraints
implemented as blockers)
An Execution Model,
with similar data
structure, but
different behaviour

66.
Epic win!
http://www.slideshare.net/ziobrando/why-do-all-my-ddd-apps-look-the-same-vienna-2014

67.
Epic win!
1. EventStorming Works!
http://www.slideshare.net/ziobrando/why-do-all-my-ddd-apps-look-the-same-vienna-2014

68.
Epic win!
1. EventStorming Works!
2. I was right 4 years ago!!
http://www.slideshare.net/ziobrando/why-do-all-my-ddd-apps-look-the-same-vienna-2014

69.
Oversimplified, but…

70.
Oversimplified, but…
1) Sketch a logical
separation of
bounded contexts

71.
Oversimplified, but…
1) Sketch a logical
separation of
bounded contexts
2) Define a local copy of
the draft BC: only a few
operations required

72.
Oversimplified, but…
1) Sketch a logical
separation of
bounded contexts
2) Define a local copy of
the draft BC: only a few
operations required
3) “Publish” the key
event, with all the
relevant data

73.
Oversimplified, but…
1) Sketch a logical
separation of
bounded contexts
2) Define a local copy of
the draft BC: only a few
operations required
3) “Publish” the key
event, with all the
relevant data
4) Use the published data to
instantiate a valid object in
the execution BC

74.
Or, more explicitly…

75.
Oversimplification?
This one is probably not the only
dependency…
Who knows what else can be there…
…

76.
Asymmetries

77.
Whoever
advocates LEGO
as an analogy to
software
development
hasn’t been doing
much LEGO lately

78.
LEGO Entropy laws
Mixing LEGO boxes takes seconds
separating LEGO boxes takes ages

79.
Or, maybe, it just
requires some
time…

80.
LEGO Entropy laws
Mixing LEGO boxes takes seconds
separating LEGO boxes takes ages
Moving a few pieces is reversible…
…until you forget
Then you loose control and call it “a
mess”

81.
Identify the right
bounded contexts
as early as
possible
…model & linguistic boundaries only…
In greenfield….

82.
In brownfield…

83.
In brownfield…

84.
Boy Scout Rule:
Leave the
campground
cleaner than you
found it

85.
The Big Ball of Mud

86.
The Big Ball of Mud
Look, a code
smell!!!

87.
The Big Ball of Mud
Look, a code
smell!!!
I’ve found
one too!!

88.
The Big Ball of Mud
Look, a code
smell!!!
I’ve found
one too!!
i’ve founds
dozens of
them!!

89.
The Big Ball of Mud
Look, a code
smell!!!
I’ve found
one too!!
i’ve founds
dozens of
them!!
Let’s
rename a few
classes…

90.
… it takes a lot
of perseverance…

91.
…It ignores
problem
number one!!

92.
There’s asymmetry
in payoffs too

93.
Or, more explicitly…

94.
Or, more explicitly…
Evolution here will
have a lot less
ripple effects… a
safer place to
improve!

95.
Or, more explicitly…
Evolution here will
have a lot less
ripple effects… a
safer place to
improve!
And here situation
is better too…

96.
Or, more explicitly…
Evolution here will
have a lot less
ripple effects… a
safer place to
improve!
And here situation
is better too…
1) we are reducing
the number of
people related to a
model

97.
Or, more explicitly…
Evolution here will
have a lot less
ripple effects… a
safer place to
improve!
And here situation
is better too…
1) we are reducing
the number of
people related to a
model
2) we are driven by business,
not by smells

98.
Smell is a good
driver if you have
no idea where the
money is

99.
Refactoring danger zone
In code:
Dependencies
Compiler
Tests
In the database
A lot harder to know who will be
affected

100.
It’s not the
cleanup, it’s the
associated risk
It takes only one violation to get into “We have no idea” zone

101.
There’s asymmetry
in refactoring
documentation…

102.
Unclear payoff ->
Risk avoidance
clear payoff ->
Risk Management

103.
What happens when
you discover the
bottleneck?
…maybe not what you expected…

104.
found the bottleneck, now what?

105.
found the bottleneck, now what?
Write some documentation?

106.
found the bottleneck, now what?
Write some documentation?
Call another meeting?

107.
found the bottleneck, now what?
Write some documentation?
Call another meeting?
Let’s think about it!

108.
found the bottleneck, now what?
Write some documentation?
Call another meeting?
Let’s think about it!

109.
found the bottleneck, now what?
Write some documentation?
Call another meeting?
Let’s think about it!
… write a prototype?

110.
found the bottleneck, now what?
Write some documentation?
Call another meeting?
Let’s think about it!
… write a prototype?
implementing a solution?

111.
found the bottleneck, now what?

112.
found the bottleneck, now what?
Write some documentation?

113.
found the bottleneck, now what?
Write some documentation?
Call another meeting?

114.
found the bottleneck, now what?
Write some documentation?
Call another meeting?
Let’s think about it!

115.
found the bottleneck, now what?
Write some documentation?
Call another meeting?
Let’s think about it!

116.
found the bottleneck, now what?
Write some documentation?
Call another meeting?
Let’s think about it!
… write a prototype?

117.
#protip
schedule a free
day after an
EventStorming

118.
But the scary
thing is…

119.
Some companies
attacked the
problem, some
didn't

120.
Single
discriminating
factor?

121.
The Dungeon
Master
https://medium.com/@ziobrando/the-rise-and-fall-of-the-dungeon-master-c2d511eed12f#.rtbyh8uid
(yes I am aware that this one is the Star Wars emperor)

122.
A few lessons
rationality doesn’t explain everything
habits, unconscious, we’re not
machines.
Passion and Pride can become
attachment
LEARNING can’t be skipped or
accelerated: sometimes things need
to be discovered again

123.
“It’s Paytime!”
Sincerely,
Technical Debt

124.
Strong emotions
How would what if three lines of
your code created a million euro
hole?
Code persist, but the context is
gone
It’s how people feel, not how they
should that drives some behaviour.

125.
Are people
feeling safe in
changing?

126.
Do they have
options?
Legacy is whatever you’re afraid to change

127.
Culture is a
better asset than
code
Safety, Experiments, …and component size too!

128.
Conclusions
…maybe not what you expected…

129.
Enables cross-
perspective
conversation
Software design, User Experience, Business Modelling,
Lean etc.

130.
Can lead you to
unexpected places
apparently, you cannot choose what your problem is

131.
Stop building
monoliths
I know you won’t … it’s for slideshare. ;-)

132.
I wasn’t explicit enough

133.
Data Centric
applications are
damaging your
business
I wasn’t explicit enough

134.
Data Centric
applications are
damaging your
business
The only thing that keeps companies in the market is
that competitors are in the same situation…
I wasn’t explicit enough

135.
There’s a
recurring way out

136.
And a recurring
problem too
#DungeonMaster

137.
Stop ignoring the
culture
We are not rational human beings 24H/day
Emotions are driving technical choices more than you think

138.
Thank you!

139.
References
• www.eventstorming.com
• EventStormers on Google+
• https://plus.google.com/u/0/communities/
113258571348605620818
• LeanPub book in progress:
• http://leanpub.com/introducing_eventstorming
• Blog:
• https://medium.com/@ziobrando
• http://ziobrando.blogspot.com
• Twitter: @ziobrando
• Trainings & Workshop facilitation:
• http://www.avanscoperta.it