Refactoring Monoliths the DDD way. This is what we can expect.

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…

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

12. 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

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. EventStorming
blends lean and
Theory of
constraints into
Software
Development and
Domain-Driven
Design

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

17. Bottleneck
Main Constraint for a system
throughput

18. 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

20. Can’t find
the heart…

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

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

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

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

25. 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…

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

27. What does a
bottleneck look
like?

28. Digging into the flow

29. Unrolling it…
Business processes expose a
repeatable structure

30. Let’s look deeper

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

32. Let’s look deeper
Here is where the
system is making
decisions:
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
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
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

36. 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

37. 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

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

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

40. 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

41. 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

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

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

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

45. And the winner is…

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

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

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

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

51. Annoying anti-
patterns in Legacy
code

52. The Big Ball of Mud

53. Recurring anti-pattern

54. “That’s our key class”

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

57. Everybody agrees
what an order is?

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

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

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

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

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

63. The Big Ball of Mud

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

65. The solution

66. The solution
A Draft Model with
loose integrity
constraints

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

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

69. 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

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

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

72. 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

73. Oversimplified, but…

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

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

76. 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

77. 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

78. Or, more explicitly…

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

80. Asymmetries

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

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

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

85. 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”

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

87. In brownfield…

88. In brownfield…

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

90. The Big Ball of Mud

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

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

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

94. 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…

95. … it takes a lot
of perseverance…

96. …It ignores
problem
number one!!

97. There’s asymmetry
in payoffs too

98. Or, more explicitly…

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

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

101. 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

102. 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

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

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

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

106. There’s asymmetry
in refactoring
documentation…

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

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

110. found the bottleneck, now what?

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

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

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

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!
… write a prototype?

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

118. found the bottleneck, now what?

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

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

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

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

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

124. #protip
schedule a free
day after an
EventStorming

125. But the scary
thing is…

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

127. Single
discriminating
factor?

129. 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)

131. 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

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

133. 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.

134. Are people
feeling safe in
changing?

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

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

137. Conclusions
…maybe not what you expected…

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

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

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

141. I wasn’t explicit enough

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

143. 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

144. There’s a
recurring way out

145. And a recurring
problem too
#DungeonMaster

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

147. Thank you!

148. 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