Software development is not one size fits all. Domain-Driven Design is significant where there's high complexity and high value. In these areas different tools might be needed. EventStorming is the best way I know to gather requirements in a complex environment, and also maps with CQRS/ES architecture perfectly.

1. #CDays14 – Milano 25, 26 e 27 Febbraio 2014
Idea —> Post-It —>
Test Verdi
Idea
Stickies
Green Bar
avanscoperta
@ziobrando
(original concept with @andreabalducci)

2. About me
@ziobrando
I do something else instead
@ziobrandoAbout me
avanscoperta
#DDD
#Agile
#Lean
#Entrepreneur
#Developer
#EventStorming
#Coach
#Facilitator
#Consultant

3. Let’s start from
here…
#Entrepreneur
#Lean

4. Theory
of
Constraints

8. Look for the bottleneck!

10. Improving the
bottleneck, improves
the whole system

11. Other improvements
have little or
negligible impact

12. I want to find my
bottleneck
#Entrepreneur

13. I help my customers
to find their
bottleneck
#Lean #Consultant

14. Should I care about
it?
#Developer

15. Yes

16. Customers will need
to reduce costs in non
bottleneck areas

17. Customers will need
to improve
performances in
bottleneck areas

19. Unfortunately…

20. Customers might not
know about their
bottleneck

21. Customers might not
want to talk about
their
bottleneck
#Developer

22. How can we do the
right thing?

23. Domain-Driven
Design
Not what you’ll expect
#Developer #DDD

24. “Domain-Driven
Design is an
architectural
approach”

25. Yes, this is
still what it looks
like…

26. It’s actually worse
than this
#DDD

27. “Domain-Driven
Design is an
architectural
approach”

28. “DDD is an
architectural
approach to over-
engineered solutions”

29. This is what we see at
the end

30. SPOILER ALERT

32. “Why did it take you so
much to get there?”

33. “It’s the journey not
the destination”

34. But…

35. But…

36. Yep, not all journeys
are equal

37. Only some journeys
are worth taking

38. That’s what we call
“Core Domain”
#DDD

39. DDD supports a
process of continuous
evolution

40. It’s not for writing
software faster

41. It’s for rewriting
software frequently

42. Hypothesis: “DDD is an
approach to software
development for guys
that can’t get it right
the first time”

43. Hmmm…

44. You need a robust
architecture for doing
this

45. And in 2004,
Entities, Value
Objects and so on
was the only viable
option

46. DDD is not an
architecture,
but it needs a good
one badly
#DDD

47. Requirements
Gathering
Yep, that’s a common name
for our problem
#Developer #DDD #Agile

48. How do we collect
requirements?

50. Sequential strategy
Time...

53. way too late…

54. A simple solution
Put all the key stakeholders
in the same room and
sketch a model together

55. Event Storming!
Exploring the Domain

56. Not this way

59. This is way betterEventstorming Short

60. Sequential gathering
Time…

61. EventStorming
Time…

62. Active Collaboration
All participant should
actively contribute

63. One
Man
One
Marker

64. Chaotic eats
sequential for
breakfast

65. and with a few
tricks…
#Agile #Coach#Facilitator

66. STOP Modelling NOW!!!

67. Leveraging
developer’s brain
(something you won’t admit

68. We basically made
the business problem
less boring

70. It’s not about being
faster
That’s still thinking linearly

71. What’s Eventstorming
It’s an act of
deliberate
collective
learning

72. We discover a lot

73. Things we swept under the carpet

74. The Big Picture
All the business process(es)
end-to-end
and beyond!

75. Unlimited Modelling Space
My problem is...
BIGGER

76. Guerrilla modeling

77. Once you see it…

78. Conquer first
Divide later

80. Unlimited surface
You don’t know the size of the
problem before exploring it

81. Big Picture approaches
-Impact Mapping -> Gojko Adzic
-Specification Workshop -> Gojko Adzic
-User Story Mapping -> Jeff Patton
-Value Stream Mapping -> Stephen Parry
(and others, of course)
-...

82. In EventStorming
-All key stakeholders in the same room
-With an unlimited modelling surface
-Modelling key processes starting from
Domain Events

83. Domain Events
Sometimes I do things for a reason
#DDD
#Developer
#EventStorming

85. along a timeline

87. Capture spontaneous
complexity

90. Can’t you do the
same with an activity
diagram?

91. Of course!

92. too afraid of the conference code of
conduct to tell the joke
Could you please laugh anyway?

94. instead…

95. Humans
evolved as
the most
efficient
creatures to
spot someone
else’s
mistakes

96. Let’s use that!

97. Business conversation
Technical
conversation

98. Observe
Language
Interaction
Body Language

103. We have a big a
behavioural model of
the whole thing, now
what?

104. We can have the
bottleneck emerge
BIG
problem
here!!!

106. We can finally
do the right thing
#DDD
#Lean #Entrepreneur
#Developer
Please
ignore what
your brain is
suggesting
right now

107. Can we also
do it right?
#DDD #Developer

108. Business conversation
Domain-­‐Driven
Design
Event
Sourcing
CQRS
Event
Driven
Architecture
a
business-­‐driven
model
evolution

109. Pain-Oriented EventStorming
Focus on
Explore normally foggy areas
Let an action plan emerge!
Pain
Point
Someone
else’s pain
point

110. Pain Oriented
Show the whole flow
Display the pain
Explore
Choose
Eve
Pai

111. Danger Zone

112. best advice comes from
KEEP
YOUR
MOUTH
SHUT

113. but please…

114. Impact Mapping
What is the
expected
outcome?

115. Backward
implementation

116. POES as retrospective background
Big Picture first
Retrospective scope explicitly
widened
Facilitated root cause analysis
Hints for collaboration

118. As a learning tool
Every new hire in avanscoperta
gets an EventStorming session
The result is visible on the
wall
…
I am here! :-)

119. Maximise Learning?

120. EventStorming as a
Learning Tool

121. EventStorming as an
experiment planner

122. Many others are pointing here…
-Lean Startup
-Lean UX
-Popcorn Flow
-Small Controlled Experiments
-Modellathlon

123. Business experiments
Implementation
experiments

124. Modelling
Sympathy
Don’t know what it means
but sounds so cool

125. Simple as that
#DDD

126. Aggregates
Workshop
Participant
added
Participant
removed
Add
participant
Remove
participant
Maximum
Capacity
reached

128. class Customer
attr_reader :name,
:surname,
:address,
:picture,
:email,
:id,
:status
# ...
end
<— The system will
probably care only
about this one
<— User will need to
see all these..

129. Yep, there is no such
thing as “the model”

130. Oh, sh*t!

131. “…I used that
architecture”

132. Application
ApplicationApplication
Application
Application
Database
Application
Application
Database
Data-based integration
Application

133. Read Model
!=
Write Model

134. CQRS

135. Aggregate
Aggregate
Command
Command
Event
Event
Event
Event
Event
Event
EventEvent
Event store
Domain Model
Projection
Projection
Read Model
DTO
DTO
Presentation
UI
UI
UI
UI
Old picture… please
ignore the colors

136. It’s not about speed

138. It’s about clarity

140. “… and after you
mixed the ingredients,
now separate them”

141. Commands
Add Item to
cart
Customer
Article
Details

142. UI Constraints
Item pageProjection
(read model)
Command
User
Price
Special
offer!

143. Can I influence the
user decision?
UX
Readability
Information
Images
Speed

144. Can I improve the
quality of the user
decision?
UX
Readability
Information
Images
Speed

145. Processes
Ticket
bought
Welcome
process
Send
welcome e-
mail

147. Can I improve
processes?
Reliability
Speed Automation
Composability

148. External Systems
Thermometer Temperature
registered

149. External Systems
Command External
System

150. Design Level
Active collaboration
Wisdom of the crowd
Visually consistent models
Big visible

151. overengineered?

153. I m
ean
it!
If you
don’t I am
gonna
find
where you
live!

154. Hey, you
mentioned…
…the green bar
#Developer #DDD #Agile

155. Cucumber to the
rescue
Scenario Outline: Manually opening a project finances account
When I open a project account called <project name>
Then project account should be opened for <project name>
And project <project name> should be visible in the projects list
Examples:
| project name |
| Project Alpha |
| Project Omega |

156. Executing a Command
When(/^I open a project account called (.*)$/) do |project_name|
params = {
'headline' => project_name
}
command = OpenProject.from_params(params)
@project_account_id = command.aggregate_id
Quindi::Application::ProjectFinancesCommandHandler.handle(command)
end

157. Checking a Domain Event
Then(/^project account should be opened for (.*)$/) do |expected_headline|
eventually(timeout: 0.8) {
last_project_opened_event = @event_logger.received['ProjectOpened'].last
expect(last_project_opened_event).to_not be_nil
expect(last_project_opened_event).to be_a ProjectOpened
expect(last_project_opened_event.headline).to eq expected_headline
}
end

158. Checking a Read Model
And(/^project (.*) should be visible in the projects list$/) do |project_name|
fail 'Please set @project_account_id ' unless @project_account_id
eventually(timeout: 0.5) {
visible_project =
Quindi::Application::ProjectList.find_by_id(@project_account_id)
expect(visible_project).not_to be_nil
expect(visible_project['headline']).to eq project_name
}
end

159. Wrapping up
Doing the right thing matters
Doing it right matters too
Discovering it matters too
Have a look to CQRS/ES
EventStorming Friends

161. References
http://ziobrando.blogspot.com
#eventstormers on Google+:
https://plus.google.com/u/0/

162. avanscoperta

163. Thanks
@ziobrando
avanscoperta