Embed Size (px)
Citation preview
Guerrilla Domain Driven DesignAll the really important stuff you need to know about Domain Driven Design
Jak Charlton
www.thinkddd.comGoogle+ : [email protected] : @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?
