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, brieflyAgile 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 bitsShort 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 used when we calculate the insurance premium.

We can do that quite easily if we create another adjustment type and modify the stored proc.

What is this stored proc you talk about?

Never mind, it’s kind of like a spreadsheet macro.

So how will this work as an adjustment?

Well, we already have adjustment types for loyalty and zero-claim discounts, so we can add risk factor as another type.

But loyalty and zero-claim are benefits, not discounts!

Well, all those things are handled 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 rightBusiness Story

As a new customerI want to know how much extra my insurance will cost if I use my private car for business purposesSo that I can check if I am still within budget

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


The Neglected VerbNouns are easy

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

CompleteConfirmedAcceptedAuthorized

Complete - Filled inAccepted - Planner processes transferAuthorized - Manager approves transferConfirmed - Ship is notified of transfer


Considering a ModelDesign 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 ModelLayered approach:

Presentation / User Interface Application Layer (stateless, eg. Menu items) Domain / Business Logic Infrastructure / Persistence (DB)

Identify contextsIdentify interfacesLook for behaviourLook 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 DomainDomains are often complexMost domains have subtletiesYou 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 1Given the market value of my car is R100,000And the car is used for private purposes onlyAnd the risk factor is 0.15% for cars valued R100,000When the premium is calculatedThen the premium should be R150


In practice…@Testclass CalcuatePremiumForCars {

private CarPremiumCalculator calculator = new CarPremiumCalculator;

public void carUsedForPrivateUseOnly() {// Given the market value of my car is R100,000Money marketValue = new Money(100000);// and the car is used for private purposes onlyboolean isForPrivateUse = true;// and the risk factor is currently 0.15% for cars

valued R100,000calculator.addRiskFactor(1000000, 0.15);// When the premium is calculatedMoney premium = calculator.calculate(marketValue,

isForPrivateUse);// Then the premium should be R150assertEquals(new Money(150), premium);

}}


Lessons from KRSDDD isn’t just for architectsWe teach DDD to our internsIt 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 2900Lorraine Steyn: [email protected] Johnson: [email protected]

http://www.krs.co.za/

mailto:[email protected]

mailto:[email protected]

Technology

Domain Driven Design in an Agile World