Idea stickies green bar - Wroclaw edition
-
Upload
alberto-brandolini -
Category
Software
-
view
608 -
download
0
Transcript of Idea stickies green bar - Wroclaw edition
#CDays14 – Milano 25, 26 e 27 Febbraio 2014
Idea —> Post-It —> Test Verdi
Idea
Stickies
Green Baravanscoperta
@ziobrando
(original concept with @andreabalducci)
About me@ziobrando
I do something else instead
@ziobrandoAbout me
avanscoperta
#DDD
#Agile
#Lean
#Entrepreneur
#Developer
#EventStorming
#Coach
#Facilitator
#Consultant
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 strategyTime...
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 gatheringTime…
EventStormingTime…
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 surfaceYou 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 Patton
-Value Stream Mapping -> Stephen Parry (and others, of course)
-...
In EventStorming
-All key stakeholders in the same room
-With an unlimited modelling surface
-Modelling key processes starting from Domain Events
Domain EventsSometimes 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 business-‐driven model evolution
Pain-Oriented EventStorming
Focus on
Explore normally foggy areas
Let an action plan emerge!
Pain PointSomeone else’s pain point
Pain Oriented
Show the whole flow Display the pain Explore Choose
EvePai
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
Hints for collaboration
As a learning toolEvery new hire in avanscoperta gets an EventStorming session
The result is visible on the wall …
I am here! :-)
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 system will probably care only about this one
<— User will need to see all these..
Yep, there is no such thing as “the model”
Oh, sh*t!
“…I used that architecture”
Application
ApplicationApplication
Application
Application
Database
ApplicationApplica
tion
Database
Data-based integration
Applicatio
n
Read Model !=
Write Model
CQRS
Aggregate
Aggregate
Command
Command
Event
Event
Event
EventEvent
EventEventEventEvent store
Domain Model
Projection
Projection
Read Model
DTO
DTO
Pres
enta
tion
UI
UI
UI
UI
Old picture… please ignore the colors
It’s not about speed
It’s about clarity
“… and after you mixed the ingredients, now separate them”
CommandsAdd Item to cart
Customer
Article Details
UI Constraints
Item pageProjection(read model)
Command
UserPrice
Special offer!
Can I influence the user decision?
UXReadability
Information
ImagesSpeed
Can I improve the quality of the user
decision?UX
ReadabilityInformation
ImagesSpeed
Processes
Ticket bought
Welcome process
Send welcome e-mail
Can I improve processes?
ReliabilitySpeed 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 mean 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 <project name> Then project account should be opened for <project name> And project <project name> should be visible in the projects listExamples: | project name | | Project Alpha | | Project Omega |
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
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
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
Wrapping up
Doing the right thing matters
Doing it right matters too
Discovering it matters too
Have a look to CQRS/ES
EventStorming # Friends
References
http://ziobrando.blogspot.com #eventstormers on Google+: https://plus.google.com/u/0/
avanscoperta
Thanks@ziobrando
avanscoperta