Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Idea —> Post-It —>
Test Verdi
Idea
Stickies
Green Bar
avanscoperta
@ziobrando
...
About me
@ziobrando
I do something else instead
@ziobrandoAbout me
avanscoperta
#DDD
#Agile
#Lean
#Entrepreneur
#Developer...
Let’s start from
here…
#Entrepreneur
#Lean
Theory
of
Constraints
Look for the bottleneck!
Improving the
bottleneck, improves
the whole system
Other improvements
have little or
negligible impact
I want to find my
bottleneck
#Entrepreneur
I help my customers
to find their
bottleneck
#Lean #Consultant
Should I care about
it?
#Developer
Yes
Customers will need
to reduce costs in non
bottleneck areas
Customers will need
to improve
performances in
bottleneck areas
Unfortunately…
Customers might not
know about their
bottleneck
Customers might not
want to talk about
their
bottleneck
#Developer
How can we do the
right thing?
Domain-Driven
Design
Not what you’ll expect
#Developer #DDD
“Domain-Driven
Design is an
architectural
approach”
Yes, this is
still what it looks
like…
It’s actually worse
than this
#DDD
“Domain-Driven
Design is an
architectural
approach”
“DDD is an
architectural
approach to over-
engineered solutions”
This is what we see at
the end
SPOILER ALERT
“Why did it take you so
much to get there?”
“It’s the journey not
the destination”
But…
But…
Yep, not all journeys
are equal
Only some journeys
are worth taking
That’s what we call
“Core Domain”
#DDD
DDD supports a
process of continuous
evolution
It’s not for writing
software faster
It’s for rewriting
software frequently
Hypothesis: “DDD is an
approach to software
development for guys
that can’t get it right
the first time”
Hmmm…
You need a robust
architecture for doing
this
And in 2004,
Entities, Value
Objects and so on
was the only viable
option
DDD is not an
architecture,
but it needs a good
one badly
#DDD
Requirements
Gathering
Yep, that’s a common name
for our problem
#Developer #DDD #Agile
How do we collect
requirements?
Sequential strategy
Time...
way too late…
A simple solution
Put all the key stakeholders
in the same room and
sketch a model together
Event Storming!
Exploring the Domain
Not this way
This is way betterEventstorming Short
Sequential gathering
Time…
EventStorming
Time…
Active Collaboration
All participant should
actively contribute
One
Man
One
Marker
Chaotic eats
sequential for
breakfast
and with a few
tricks…
#Agile #Coach#Facilitator
STOP Modelling NOW!!!
Leveraging
developer’s brain
(something you won’t admit
We basically made
the business problem
less boring
It’s not about being
faster
That’s still thinking linearly
What’s Eventstorming
It’s an act of
deliberate
collective
learning
We discover a lot
Things we swept under the carpet
The Big Picture
All the business process(es)
end-to-end
and beyond!
Unlimited Modelling Space
My problem is...
BIGGER
Guerrilla modeling
Once you see it…
Conquer first
Divide later
Unlimited surface
You don’t know the size of the
problem before exploring it
Big Picture approaches
-Impact Mapping -> Gojko Adzic
-Specification Workshop -> Gojko Adzic
-User Story Mapping -> Jeff Pat...
In EventStorming
-All key stakeholders in the same room
-With an unlimited modelling surface
-Modelling key processes star...
Domain Events
Sometimes I do things for a reason
#DDD
#Developer
#EventStorming
along a timeline
Capture spontaneous
complexity
Can’t you do the
same with an activity
diagram?
Of course!
too afraid of the conference code of
conduct to tell the joke
Could you please laugh anyway?
instead…
Humans
evolved as
the most
efficient
creatures to
spot someone
else’s
mistakes
Let’s use that!
Business conversation
Technical	
  conversation
Observe
Language
Interaction
Body Language
We have a big a
behavioural model of
the whole thing, now
what?
We can have the
bottleneck emerge
BIG
problem
here!!!
We can finally
do the right thing
#DDD
#Lean #Entrepreneur
#Developer
Please
ignore what
your brain is
suggesting
right now
Can we also
do it right?
#DDD #Developer
Business conversation
Domain-­‐Driven	
  Design	
  
Event	
  Sourcing	
  
CQRS	
  
Event	
  Driven	
  Architecture	
  
a	
...
Pain-Oriented EventStorming
Focus on
Explore normally foggy areas
Let an action plan emerge!
Pain
Point
Someone
else’s pai...
Pain Oriented
Show the whole flow
Display the pain
Explore
Choose
Eve
Pai
Danger Zone
best advice comes from
KEEP
YOUR
MOUTH
SHUT
but please…
Impact Mapping
What is the
expected
outcome?
Backward
implementation
POES as retrospective background
Big Picture first
Retrospective scope explicitly
widened
Facilitated root cause analysis
H...
As a learning tool
Every new hire in avanscoperta
gets an EventStorming session
The result is visible on the
wall
…
I am h...
Maximise Learning?
EventStorming as a
Learning Tool
EventStorming as an
experiment planner
Many others are pointing here…
-Lean Startup
-Lean UX
-Popcorn Flow
-Small Controlled Experiments
-Modellathlon
Business experiments
Implementation	
  experiments
Modelling
Sympathy
Don’t know what it means
but sounds so cool
Simple as that
#DDD
Aggregates
Workshop
Participant
added
Participant
removed
Add
participant
Remove
participant
Maximum
Capacity
reached
class Customer



attr_reader :name,

:surname,

:address,

:picture,

:email,

:id,

:status



# ...



end
<— The syste...
Yep, there is no such
thing as “the model”
Oh, sh*t!
“…I used that
architecture”
Application
ApplicationApplication
Application
Application
Database
Application
Application
Database
Data-based integratio...
Read Model
!=
Write Model
CQRS
Aggregate
Aggregate
Command
Command
Event
Event
Event
Event
Event
Event
EventEvent
Event store
Domain Model
Projection
Pro...
It’s not about speed
It’s about clarity
“… and after you
mixed the ingredients,
now separate them”
Commands
Add Item to
cart
Customer
Article
Details
UI Constraints
Item pageProjection
(read model)
Command
User
Price
Special
offer!
Can I influence the
user decision?
UX
Readability
Information
Images
Speed
Can I improve the
quality of the user
decision?
UX
Readability
Information
Images
Speed
Processes
Ticket
bought
Welcome
process
Send
welcome e-
mail
Can I improve
processes?
Reliability
Speed Automation
Composability
External Systems
Thermometer Temperature
registered
External Systems
Command External
System
Design Level
Active collaboration
Wisdom of the crowd
Visually consistent models
Big visible
overengineered?
I m
ean
it!
If you
don’t I am
gonna
find
where you
live!
Hey, you
mentioned…
…the green bar
#Developer #DDD #Agile
Cucumber to the
rescue
Scenario Outline: Manually opening a project finances account

When I open a project account called...
Executing a Command
When(/^I open a project account called (.*)$/) do |project_name|

params = {

'headline' => project_na...
Checking a Domain Event
Then(/^project account should be opened for (.*)$/) do |expected_headline|



eventually(timeout: ...
Checking a Read Model
And(/^project (.*) should be visible in the projects list$/) do |project_name|

fail 'Please set @pr...
Wrapping up
Doing the right thing matters
Doing it right matters too
Discovering it matters too
Have a look to CQRS/ES
Eve...
References
http://ziobrando.blogspot.com
#eventstormers on Google+:
https://plus.google.com/u/0/
avanscoperta
Thanks
@ziobrando
avanscoperta
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Idea stickies green bar - Wroclaw edition
Upcoming SlideShare
Loading in …5
×

Idea stickies green bar - Wroclaw edition

2,739 views

Published on

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.

Published in: Software

Idea stickies green bar - Wroclaw edition

  1. 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. 2. About me @ziobrando I do something else instead @ziobrandoAbout me avanscoperta #DDD #Agile #Lean #Entrepreneur #Developer #EventStorming #Coach #Facilitator #Consultant
  3. 3. Let’s start from here… #Entrepreneur #Lean
  4. 4. Theory of Constraints
  5. 5. Look for the bottleneck!
  6. 6. Improving the bottleneck, improves the whole system
  7. 7. Other improvements have little or negligible impact
  8. 8. I want to find my bottleneck #Entrepreneur
  9. 9. I help my customers to find their bottleneck #Lean #Consultant
  10. 10. Should I care about it? #Developer
  11. 11. Yes
  12. 12. Customers will need to reduce costs in non bottleneck areas
  13. 13. Customers will need to improve performances in bottleneck areas
  14. 14. Unfortunately…
  15. 15. Customers might not know about their bottleneck
  16. 16. Customers might not want to talk about their bottleneck #Developer
  17. 17. How can we do the right thing?
  18. 18. Domain-Driven Design Not what you’ll expect #Developer #DDD
  19. 19. “Domain-Driven Design is an architectural approach”
  20. 20. Yes, this is still what it looks like…
  21. 21. It’s actually worse than this #DDD
  22. 22. “Domain-Driven Design is an architectural approach”
  23. 23. “DDD is an architectural approach to over- engineered solutions”
  24. 24. This is what we see at the end
  25. 25. SPOILER ALERT
  26. 26. “Why did it take you so much to get there?”
  27. 27. “It’s the journey not the destination”
  28. 28. But…
  29. 29. But…
  30. 30. Yep, not all journeys are equal
  31. 31. Only some journeys are worth taking
  32. 32. That’s what we call “Core Domain” #DDD
  33. 33. DDD supports a process of continuous evolution
  34. 34. It’s not for writing software faster
  35. 35. It’s for rewriting software frequently
  36. 36. Hypothesis: “DDD is an approach to software development for guys that can’t get it right the first time”
  37. 37. Hmmm…
  38. 38. You need a robust architecture for doing this
  39. 39. And in 2004, Entities, Value Objects and so on was the only viable option
  40. 40. DDD is not an architecture, but it needs a good one badly #DDD
  41. 41. Requirements Gathering Yep, that’s a common name for our problem #Developer #DDD #Agile
  42. 42. How do we collect requirements?
  43. 43. Sequential strategy Time...
  44. 44. way too late…
  45. 45. A simple solution Put all the key stakeholders in the same room and sketch a model together
  46. 46. Event Storming! Exploring the Domain
  47. 47. Not this way
  48. 48. This is way betterEventstorming Short
  49. 49. Sequential gathering Time…
  50. 50. EventStorming Time…
  51. 51. Active Collaboration All participant should actively contribute
  52. 52. One Man One Marker
  53. 53. Chaotic eats sequential for breakfast
  54. 54. and with a few tricks… #Agile #Coach#Facilitator
  55. 55. STOP Modelling NOW!!!
  56. 56. Leveraging developer’s brain (something you won’t admit
  57. 57. We basically made the business problem less boring
  58. 58. It’s not about being faster That’s still thinking linearly
  59. 59. What’s Eventstorming It’s an act of deliberate collective learning
  60. 60. We discover a lot
  61. 61. Things we swept under the carpet
  62. 62. The Big Picture All the business process(es) end-to-end and beyond!
  63. 63. Unlimited Modelling Space My problem is... BIGGER
  64. 64. Guerrilla modeling
  65. 65. Once you see it…
  66. 66. Conquer first Divide later
  67. 67. Unlimited surface You don’t know the size of the problem before exploring it
  68. 68. 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) -...
  69. 69. In EventStorming -All key stakeholders in the same room -With an unlimited modelling surface -Modelling key processes starting from Domain Events
  70. 70. Domain Events Sometimes I do things for a reason #DDD #Developer #EventStorming
  71. 71. along a timeline
  72. 72. Capture spontaneous complexity
  73. 73. Can’t you do the same with an activity diagram?
  74. 74. Of course!
  75. 75. too afraid of the conference code of conduct to tell the joke Could you please laugh anyway?
  76. 76. instead…
  77. 77. Humans evolved as the most efficient creatures to spot someone else’s mistakes
  78. 78. Let’s use that!
  79. 79. Business conversation Technical  conversation
  80. 80. Observe Language Interaction Body Language
  81. 81. We have a big a behavioural model of the whole thing, now what?
  82. 82. We can have the bottleneck emerge BIG problem here!!!
  83. 83. We can finally do the right thing #DDD #Lean #Entrepreneur #Developer Please ignore what your brain is suggesting right now
  84. 84. Can we also do it right? #DDD #Developer
  85. 85. Business conversation Domain-­‐Driven  Design   Event  Sourcing   CQRS   Event  Driven  Architecture   a  business-­‐driven  model  evolution  
  86. 86. Pain-Oriented EventStorming Focus on Explore normally foggy areas Let an action plan emerge! Pain Point Someone else’s pain point
  87. 87. Pain Oriented Show the whole flow Display the pain Explore Choose Eve Pai
  88. 88. Danger Zone
  89. 89. best advice comes from KEEP YOUR MOUTH SHUT
  90. 90. but please…
  91. 91. Impact Mapping What is the expected outcome?
  92. 92. Backward implementation
  93. 93. POES as retrospective background Big Picture first Retrospective scope explicitly widened Facilitated root cause analysis Hints for collaboration
  94. 94. As a learning tool Every new hire in avanscoperta gets an EventStorming session The result is visible on the wall … I am here! :-)
  95. 95. Maximise Learning?
  96. 96. EventStorming as a Learning Tool
  97. 97. EventStorming as an experiment planner
  98. 98. Many others are pointing here… -Lean Startup -Lean UX -Popcorn Flow -Small Controlled Experiments -Modellathlon
  99. 99. Business experiments Implementation  experiments
  100. 100. Modelling Sympathy Don’t know what it means but sounds so cool
  101. 101. Simple as that #DDD
  102. 102. Aggregates Workshop Participant added Participant removed Add participant Remove participant Maximum Capacity reached
  103. 103. 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..
  104. 104. Yep, there is no such thing as “the model”
  105. 105. Oh, sh*t!
  106. 106. “…I used that architecture”
  107. 107. Application ApplicationApplication Application Application Database Application Application Database Data-based integration Application
  108. 108. Read Model != Write Model
  109. 109. CQRS
  110. 110. 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
  111. 111. It’s not about speed
  112. 112. It’s about clarity
  113. 113. “… and after you mixed the ingredients, now separate them”
  114. 114. Commands Add Item to cart Customer Article Details
  115. 115. UI Constraints Item pageProjection (read model) Command User Price Special offer!
  116. 116. Can I influence the user decision? UX Readability Information Images Speed
  117. 117. Can I improve the quality of the user decision? UX Readability Information Images Speed
  118. 118. Processes Ticket bought Welcome process Send welcome e- mail
  119. 119. Can I improve processes? Reliability Speed Automation Composability
  120. 120. External Systems Thermometer Temperature registered
  121. 121. External Systems Command External System
  122. 122. Design Level Active collaboration Wisdom of the crowd Visually consistent models Big visible
  123. 123. overengineered?
  124. 124. I m ean it! If you don’t I am gonna find where you live!
  125. 125. Hey, you mentioned… …the green bar #Developer #DDD #Agile
  126. 126. 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 |
  127. 127. 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
  128. 128. 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
  129. 129. 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
  130. 130. Wrapping up Doing the right thing matters Doing it right matters too Discovering it matters too Have a look to CQRS/ES EventStorming Friends
  131. 131. References http://ziobrando.blogspot.com #eventstormers on Google+: https://plus.google.com/u/0/
  132. 132. avanscoperta
  133. 133. Thanks @ziobrando avanscoperta

×