ddd exchange 2010: gojko adzic on ddd, tdd, bdd
DESCRIPTION
Domain Driven Design is often misunderstood as something that advocates a lot of upfront design and at odds with the evolutionary design principles of test driven development. In this presentation, Gojko Adzic will talk about reconciling the two approaches and getting the best of both worlds, and how DDD ideas play a crucial role in behaviour driven development.TRANSCRIPT
The three amigos@gojkoadzic
Effective models require a bigger picture
… but KISS and YAGNI say don't... avoid BDUF
… feature injection gives us right-size chunks
Things can blow up during modelling...
… but domain experts often can't decide on scope
...collaborative specifications cause things
to blow up quicker
DDD advocates a ubiquitous language...
… but it's very hard to ensure consistency
… evolve with specification workshops,
enforce with tests
Domain experts don't really understand low level
stuff
.... but where do we stop working with them?
...BDD outside in boundaries
...TDD emergent design to flesh out details
Emergent design leads to too much inconsistency
… especially on big teams and across boundaries
… use DDD building block patterns as guidelines
Effective iterative design requires effective regression testing
… but unit tests are bound to a particular design
… business oriented specifications do not
change
We need to capture our models and what they
mean
… but code is too low level and UML gets old very quickly...
… live specification can explain our models and
dynamics
Emergent design advocates constant
refactoring
… but in larger teams, refactoring cross cutting concerns can cause a ton of issues
… bounded contexts help us coordinate changes
Recipe for success
Use strategic design to decide what to build Use feature injection to get the scope Evolve a ubiquitous language with specification
workshops Establish guidelines with collaborative high-
level domain design TDD design below, respecting DDD guidelines Use context mapping to facilitate cross team
collaboration