How does Behaviour Driven Development (BDD) work with Domain Driven Design (DDD)

Question

My understanding of BDD is that one describes a system in user stories and then developers take those user stories and turn them into an application with the intention of adding real business value with every 'sprint' (period of software development). The result (as far as I can tell) is that the domain model emerges from the user stories throughout the development process. That is, after the first 'sprint' much of the domain model will not have been designed.

My understanding of DDD is that software development continues with reference to a full domain model, albeit an evolving one. In DDD the model is expected to change, but it is nonetheless 'complete' at all times.

This seems to be a fundamental difference between the two approaches. How have people handled this?

Answer 1

BDD done well does not produce a "complete" model. There's a reason that Dan North, the guy who came up with BDD, calls his blog "embracing uncertainty".

I find it useful these days to think of three kinds of things that we can analyze: the known, the knowable and the unknowable.

Known stuff is simple - for instance, logging in. It's well understood. We don't need to talk through the scenarios.

Knowable stuff is usually related to the domain, or to something that has been done before. This is a great place to do BDD, because it helps transfer knowledge - including the domain model - from the business to the developers. Talking through scenarios is a great way to understand stories better. It can also help us to find scenarios we've missed. Chris Matts, who's the analyst who helped put the "Given" in "Given, When, Then" calls this "breaking the model". He actually offered prizes for anyone who could come up with a scenario that wasn't covered in his model, which he uses scenarios to define and refine.

There's also the unknowable stuff. This happens whenever we're working on something new, or something we've never done before, or something in which nobody has expertise. You can tell if you're in this place because business people will start reacting with surprise when you come up with the scenarios they haven't thought of. BDD is a really great way of finding these places, but at this point you probably want to stop trying to nail down the scenarios and just try something out and get feedback instead. Your domain model, and your user stories, and your scenarios, will all gradually emerge (see the complex domain in the Cynefin model).

I know a lot of teams use BDD as a way of apparently eliminating this uncertainty. You can't eliminate it. You can only hide it until later, when the feedback from delivery comes back to bite you.

With respect to DDD, when we do it with BDD we tend to focus on those parts of the domain model that are relevant to the scenarios we're working on, though we might have an idea of the larger domain model overall. If you're using Feature Injection together with BDD you'll already have talked through most of the capabilities of the system, especially the new ones, so you'll have an idea of what kind of things are in the domain. Evolution and all other rules still apply. BDD and DDD work really, really well together, with conversations around scenarios helping to bring out the domain language. They are not fundamentally different, but completely supportive and compatible.

Please also read the answer I gave to this similar question, which features a video of Dan North and myself talking about this very topic.

Answer 2

I would include user stories, DDD and BDD as they are very very dependent of each other. I tried to summarise the link here: http://christophelecoent.wordpress.com/2013/06/17/how-to-link-user-stories-ddd-and-bdd/

I hope this picture is both simple and rich enough to explain the link between these "concepts"