Idea stickies green bar - Wroclaw edition
11 likes3,574 views
The document discusses methodologies and practices for improving software development processes, particularly focusing on identifying bottlenecks using approaches like event storming and domain-driven design (DDD). It emphasizes the importance of collaboration among key stakeholders to enhance understanding and address complexities in business processes. The content critiques traditional methods and promotes continuous evolution and experimentation as essential elements in software architecture and development.
![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](https://image.slidesharecdn.com/ideastickiesgreenbar-wroclawedition-150328164648-conversion-gate01/85/Idea-stickies-green-bar-Wroclaw-edition-157-320.jpg)
![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](https://image.slidesharecdn.com/ideastickiesgreenbar-wroclawedition-150328164648-conversion-gate01/85/Idea-stickies-green-bar-Wroclaw-edition-158-320.jpg)
Idea stickies green bar - Wroclaw edition
- 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
- 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
- 25. Yes, this is still what it looks like…
- 26. It’s actually worse than this #DDD
- 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?
- 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
- 62. Active Collaboration All participant should actively contribute
- 65. and with a few tricks… #Agile #Coach#Facilitator
- 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
- 77. Once you see it…
- 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
- 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!
- 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?
- 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
- 124. Modelling Sympathy Don’t know what it means but sounds so cool
- 125. Simple as that #DDD
- 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!
- 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”
- 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
- 147. Can I improve processes? Reliability Speed Automation Composability
- 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
- 162. avanscoperta