Folding Together

DDD and AgileQuick and Sustainable Development

of Complex Software

Eric Evans

domainlanguage.com

DDD is a Set of Driving Principles

• Focus on the Core Domain.

• Explore models in a creative collaboration of domain practitioners and software practitioners.

• Speak a Ubiquitous Language within an explicitly Bounded Context.

‘We should do a nice design, but we just don’t have time.’

‘We should do a nice design, but we just don’t have time.’

‘Modeling and design take extra time, but they pay off in the long run.’

‘Modeling and design take extra time, but they pay off in the long run.’

Modeling and design are often the quickest path to the actual goal.

What is your goal?

• Implement this user story?

• Complete a releasable set of stories with an acceptable level of bugs?

• Deliver a release that the team can continue to extend in the next release?

• Deliver a clear and cohesive user experience?

Defining Our Terms

domain A sphere of knowledge or activity.

model A system of abstractions representing selected aspects of the domain.

A model is a distilled form of domainknowledge, assumptions, rules and choices.

‘We have to get the model right first, before we write the code.’

Up Front Analysis Locks in Ignorance

• Models are distilled knowledge.

• At the beginning of a project, the team is as ignorant as it will ever be.

Why we need DDD + Agile

• Technology can distract us.

• Feature-orientation can fragment our model.

• Upfront analysis locks in ignorance.

What does DDD look like?

DDD can be undramatic.

• Walking through concrete reference scenarios

• Creative collaboration with domain practitioner

• Refinement of the ubiquitous language and therefore the model

What is a ‘special case’?

Green Bar!

Challenge your assumptions

Shift from Push to Pull

• When communications with stakeholders deteriorates.

• When solutions seem more complex than the problems.

• When velocity slows (completed work becomes a burden).

Ok. Time to pull!Now what do we actually do?

Whitepaper First Draft

• domainlanguage.com/processdraft

• Will announce second draft soon in newsletter.

Where To Fit It

• Stand Up Meetings

• Spike

• Iteration Zero

• Release Planning

Defining Our Terms

bounded contextA description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.

Bounded Context

• Modeling and design pay off within a clean, unified, bounded context.

• Shared code ownership within a context.

• One unified context is owned by one team.

Not all of a large system will be well designed.

Focus

• An area of the system is recognized as a center of frequent change.

• An area of development is strategically important.

• The user experience is losing coherence.

Focus

• Triage the Ball of Mud

• Accept the Tidy Transaction Scripts

• Leave well enough alone

DDD Tools for Agile Practitioners

• Model Exploration

– ‘Whirlpool’ Process

– (Section 3 in DDD book)

• Context Boundaries (see Chapter 14 in DDD)

• Distilling the Core (see Chapter 15 in DDD)

• Triggers to ‘pull’ modeling when needed