Agile practitioners can be design avoidant! DDD helps improve communication through ubiquitous language; improve thinking through mapping patterns; and ensuring design and reality match.

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

2. Domain Driven Design 2
Home Truths
A design should be as simple as possible,
but no simpler
Agile development is about collaboration
and communication

3. Domain Driven Design 3
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

4. Domain Driven Design 4
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

5. Domain Driven Design 5
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…

6. Domain Driven Design 6
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

7. Domain Driven Design 7
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!

8. Domain Driven Design 8
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 …

9. Domain Driven Design 9
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

10. Domain Driven Design 10
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

11. Domain Driven Design 11
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

12. Domain Driven Design 12
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

13. Domain Driven Design 13
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

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

15. Domain Driven Design 15
Entity
Value Object

16. Domain Driven Design 16
Mapping Patterns
Shared Kernel
Customer / Supplier
Conformist
Separate Ways
Anti-corruption Layer
Aggregates
Factories
Repositories

17. Domain Driven Design 17
Aggregates

18. Domain Driven Design 18
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

19. Domain Driven Design 19
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

20. Domain Driven Design 20
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);
}

21. Domain Driven Design 21
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

22. Domain Driven Design 22
Questions?
www.krs.co.za
( (021) 681 2900
Lorraine Steyn: lor@krs.co.za
Paul Johnson: paul.johnson@krs.co.za