DDD and BDD

Domain Driven Design (DDD) is about evolving a shared model of the domain letting the domain model drive the design. BDD is about establishing a shared understanding of “done” working from the outside in until you get there. DDD enables the use of BDD effectively creating software and BDD helps structure the conversations for DDD.

Transcript

1. DDD and BDD Dan North ThoughtWorks
2. © 2008 Dan North, ThoughtWorks 2 What is Domain Driven Design? “It’s about focusing on the domain and letting it affect the software very much” - Jimmy Nilsson (ADDDP)
3. © 2008 Dan North, ThoughtWorks 3 Identify the “Core Domain” A shipping company moves items around Is their core domain – Transportation? – Routing? – Knowing where things are? What if they transport precious stones? – Security? Outside the core, everything else is detail
4. © 2008 Dan North, ThoughtWorks 4 Evolve a common understanding •  Model the domain with the stakeholders •  Establish a shared understanding – which leads to a shared language •  Drive this language into everything – Classes, properties, variables, method names – Object-orientation makes this easier Evolve a Ubiquitous Language
5. Some DDD Patterns •  The obvious ones: – Entity – Value Object – Repository – Service – Factory •  Some others: – Layered Architecture – Aggregate & Aggregate Boundary – Specification (“Matcher”) © 2008 Dan North, ThoughtWorks 5
6. © 2008 Dan North, ThoughtWorks 6 “Advanced” DDD •  How to scale domain-driven design – to multiple teams? – to a system-of-systems? •  Ubiquitous Language isn’t so ubiquitous •  It’s only valid within a Bounded Context
7. © 2008 Dan North, ThoughtWorks 7 What is Behaviour-Driven Development? “It’s about focusing on the behaviour of an application from the point of view of its stakeholders” - Me :)
8. © 2008 Dan North, ThoughtWorks 8 Outside-in development Express a requirement as a Story As an Anaesthetist I want to view the Patient’s surgical history So that I can choose the most suitable gas Story 28 - View patient details
9. © 2008 Dan North, ThoughtWorks 9 Agree on “Done” Define acceptance criteria as Scenarios made up of Steps Scenario – existing patient with history Given we have a patient on file And the patient has had previous surgery When I request the Patient’s surgical history Then I see all the previous treatments
10. © 2008 Dan North, ThoughtWorks 10 Automate the scenarios Each step becomes running code In Java: @Given(“we have a patient on file”) public void createPatientOnFile() { // ... } In Ruby: Given “we have a patient on file” do # ... end
11. © 2008 Dan North, ThoughtWorks 11 Code-by-Example to implement Also known as TDD •  Start at the edges, with what you know •  Implement outermost objects and services •  Discover collaborators, working inwards – and mock them out for now •  Repeat until “Done”
12. © 2008 Dan North, ThoughtWorks 12 Then bring it all together •  Examples become unit tests – and documentation •  Scenarios become acceptance tests •  Acceptance tests become regression tests
13. © 2008 Dan North, ThoughtWorks 13 Recap – DDD and BDD •  DDD is about – evolving a shared model of the domain – letting the domain model drive the design •  BDD is about – establishing a shared understanding of “done” – working from the outside in until you get there
14. © 2008 Dan North, ThoughtWorks 14 Remind me – what’s a domain model? -  It is your stakeholder’s mental model -  “The map is not the territory” -  Ah! Got it. Right. Thanks. -  Um, so what’s a stakeholder?
15. © 2008 Dan North, ThoughtWorks 15 A stakeholder is anyone who cares •  about what the application does •  about how much it costs •  about whether it is secure •  about whether it hammers the network •  about whether it complies with the law •  about how easy it is to deploy and diagnose •  about how well it is written and architected – and how easy it is to change
16. © 2008 Dan North, ThoughtWorks 16 We have lots of stakeholders So we have lots of domains …each with their own language …all speaking at once! That’s a recipe for disaster, surely?
17. © 2008 Dan North, ThoughtWorks 17 Actually it happens all the time You want to retrieve patient records – You’re writing in C#, using NHibernate so you define class HibernatePatientRecordRepository { What if your IDE did domain-specific fonts?
18. © 2008 Dan North, ThoughtWorks 18 Even your process is a domain •  DDD has its own domain language –  Repository, Factory, Service, Entity, Value Object •  So does BDD –  Story, Scenario, Step, Example –  Given, When, Then •  These terms permeate into the code too class HibernatePatientRecordRepositoryExamples { @Test // ... }
19. © 2008 Dan North, ThoughtWorks 19 So how does DDD relate to BDD? •  DDD is how you capture the domain model your stakeholders use – and articulate problems in that domain •  BDD is the conversations you have with that language to produce software
20. © 2008 Dan North, ThoughtWorks 20 In other words: DDD enables BDD •  The domain drives your design hence Domain-Driven Design •  The behaviour drives what you develop – hence Behaviour-Driven Development
21. © 2008 Dan North, ThoughtWorks 21 Thanks •  NNUG – Jon Arild Torresdal •  Domain-driven folk – Eric Evans, Jimmy Nilsson •  Behaviour-driven folk – Chris Matts, Liz Keogh, Niclas Nilsson •  ThoughtWorks – We’re open in Sweden – woohoo!
22. © 2008 Dan North, ThoughtWorks 22 Questions? •  DDD –  Domain-Driven Design by Eric Evans –  Applying Domain-Driven Design and Patterns by Jimmy Nilsson •  BDD –  http://behaviour-driven.org •  especially good for spam –  http://jbehave.org •  JBehave 2 coming Real Soon Now ™ –  http://rspec.info •  Me –  http://dannorth.net –  dan.north@thoughtworks.com