Domain Driven Design in an Agile World

DOMAIN DRIVEN
DESIGN
Prepared for the 4th Software Engineering Colloquium
Lorraine Steyn and Paul Johnson

Domain Driven Design 2

Home Truths
A design should be as simple as possible,
but no simpler

Agile development is about collaboration
and communication


Agile, briefly
Agile practitioners can be design avoidant!
 Avoid documentation, no big upfront analysis

Scrum and Agile encourage rapid change
 Quicker route to the BOM
 No time for design?
 Small user stories lose the big picture
 Scrum is particularly Process focused, and does not
prescribe the technical approach


Agile – the good bits
Short iterations
 Deliver working software in 2 to 3 week “sprints”
Empower people
 Team ownership
 Team commitment to deliver
Structured Process through Scrum
 The ability to respond to change is Agile, through a
highly structured approach
 New ways of working: Pair programming, test-driven
development


How does DDD Help?
 Communication improved by ubiquitous language
 Between team and client
 All the way through to the code

 Design thinking improved by applying standard patterns
 Leverage off the wisdom of others
 Double edged sword if a pattern is mis-identified

 Ensure design and reality match
 Model stories and scenarios using concrete examples
 Refactor, refactor…


Ubiquitous Language
 Evolve the language, don’t define it upfront
 Client, customer, user, stakeholder, person,
accountholder, payer ???
 Bounded context

 Bridge the IT/Domain expert divide
 Remove technical aspects (server, logger etc)
 No technical jargon (stored proc, XML etc)
 Clarify business terms and insist on consistent usage
 Make it natural


In practice…
Domain Expert Developer
The correct risk factor must be We can do that quite easily if we
used when we calculate the create another adjustment type
insurance premium. and modify the stored proc.

What is this stored proc you talk Never mind, it’s kind of like a
about? spreadsheet macro.

So how will this work as an Well, we already have adjustment
adjustment? types for loyalty and zero-claim
discounts, so we can add risk
factor as another type.

But loyalty and zero-claim are Well, all those things are handled
benefits, not discounts! as adjustments in the system.
Trust me!


Ubiquitous Language Rules
 Let the model do the talking
 Look at the model (sketch) and tell a story
 Look at the code and tell the same story

 Define structured stories
 As a … I want … So that …
 Identify user value (start by understanding their world)

 Define specific scenarios that model
behaviour we can test
 Given (/and)… When … Then …


Doing it right
Business Story
As a new customer
I want to know how much extra my insurance will cost if I
use my private car for business purposes
So that I can check if I am still within budget

Scenario 1
Given the market value of my car is R100,000
And the car is used for private purposes only
And the risk factor is 0.15% for cars valued R100,000
When the premium is calculated
Then the premium should be R150


The Neglected Verb
Nouns are easy

KRS client in the Shipping industry defined
actions (verbs) for a crew transfer form:

Complete - Filled in
Accepted
Confirmed - Planner processes transfer
Authorized
Accepted - Manager approves transfer
Confirmed
Authorized - Ship is notified of transfer


Considering a Model
Design emerges…
 Communication tool
 Patterns appear as you build the model

IEEE: Software Engineering is the application of a
systematic, disciplined, quantifiable approach to
development…

Tools don’t matter: UML, BPM, any sketch can be a model

YAGNI / KISS


The Core Model
Layered approach:
 Presentation / User Interface
 Application Layer (stateless, eg. Menu items)
 Domain / Business Logic
 Infrastructure / Persistence (DB)

Identify contexts
Identify interfaces
Look for behaviour
Look for value


Entities and Value Objects
Entities
 Nouns
 Identity
 eg. Person, Sale, Stock, Vehicle

Value Objects
 We care about what an object has, not what it is
 Immutable
 Lightweight
 eg. Calendar, Price, Age, Vehicle Type


In practice…
Create a quote for a hotel booking:
 Check in date, check out date
 Number of rooms


Entity

Value Object


Mapping Patterns
Shared Kernel
Customer / Supplier
Conformist
Separate Ways
Anti-corruption Layer
Aggregates
Factories
Repositories


Aggregates


Exploring the Domain
Domains are often complex
Most domains have subtleties
You need to dig deep

Your design should improve as you go
 You have to refactor as you go

What happens if you implement the design
that you first thought of?
 You lock in your ignorance – Eric Evans


In practice…

Scenario 1
Given the market value of my car is R100,000
And the car is used for private purposes only
And the risk factor is 0.15% for cars valued R100,000
When the premium is calculated
Then the premium should be R150


In practice…
@Test
class CalcuatePremiumForCars {
private CarPremiumCalculator calculator = new CarPremiumCalculator;
public void carUsedForPrivateUseOnly() {
// Given the market value of my car is R100,000
Money marketValue = new Money(100000);
// and the car is used for private purposes only
boolean isForPrivateUse = true;
// and the risk factor is currently 0.15% for cars valued R100,000
calculator.addRiskFactor(1000000, 0.15);
// When the premium is calculated
Money premium = calculator.calculate(marketValue,
isForPrivateUse);
// Then the premium should be R150
assertEquals(new Money(150), premium);
}


Lessons from KRS
DDD isn’t just for architects
We teach DDD to our interns
It results in better software
 Forces developers to think in layers
 Concrete scenarios get developers closer to the true
business requirements quicker
 Scenarios become your tests
 Ubiquitous language breaks down barriers between
users and developers
 Better software becomes a habit


Questions?

www.krs.co.za
( (021) 681 2900
Lorraine Steyn: lor@krs.co.za
Paul Johnson: paul.johnson@krs.co.za

Domain Driven Design in an Agile World

More Related Content

What's hot (20)

Viewers also liked (6)

Similar to Domain Driven Design in an Agile World (20)

More from Lorraine Steyn (11)

Recently uploaded (20)

Domain Driven Design in an Agile World