#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