Domain Driven Design - DDDSydney 2011

Guerrilla Domain Driven DesignAll the really important stuff you need to know about Domain Driven Design

Jak Charlton

www.thinkddd.comGoogle+ : jakcharlton@gmail.comTwitter : @jakcharlton

“passionate and opinionated”

Domain Driven Design is a methodology for evolving software that closely matches our business

requirements

Domain Driven Design is a way of thinking, and a set of

priorities

Domain : a sphere of Knowledge, Activity or

Influence

For most software projects, the primary focus should be on the domain and domain knowledge

When we set out to write software we never know

enough

Software is an exploration, you never know where you

will end up

Development is iterative

Domain driven team

Get Domain Experts

Developers and domain experts must have a close

relationship

Modelling

Model out loud

Brainstorm and experiment

The model is distilled knowledge

Look for the deep models

Don’t introduce deeper models the domain experts

don’t see

The model is the backbone of a language used by all team

members

The Ubiquitous Language

Domain experts should object to inadequate terms

or structures

Developers should watch for ambiguity or inconsistency

When a term appears in multiple places, you need

context

One team, one language

The term Ubiquitous Language implies there is only one model in play, but there may be many

Keep looking at things differently, keep questioning

and challenging

Maintain an unbroken dialog with domain experts

Write it down, document continually

Documents should talk in terms of the ubiquitous

language

Documents must work for their living, and stay current

A document should not try to do what the code already

does well

If the code doesn’t already convey something well,

perhaps it should be refactored

Use explanatory models , technical models aren’t always

good at explaining things

The model and implementation are intrinsically linked

Expose your models, and avoid abstractions

Refactor when the design doesn’t express the team’s

understanding of the domain

Refactor to deeper insight

Refactor when important concepts are implicit in the

design and can be made explicit

Refactor when you can make the design more supple

Don’t aggressively refactor for the sake of it

Avoid technical virtuosity

Make it as simple as possible, but no simpler

Albert Einstein

Complex is easy, any idiot can do complex

Simple is a lot harder

Jak Charlton

Don’t risk real business value for technical purity

Live in the domain

My objective today was to make you think

I hope I have succeeded

Questions?