Domain Driven Design: Where It Meets Behaviour Driven Development

Domain driven design is an approach to building software for complicated business domains, in which the structure of the code is made to follow the structure of the domain rather than the other way round. Eric Evans set it out in 2003.

BDD and domain driven design are frequently taught together, and the reason is narrower than it looks. They share one idea, and it happens to be load-bearing for both.

The shared idea

That idea is the ubiquitous language: one vocabulary used by the business, in conversation, and inside the code, with no translation layer.

Domain driven design arrives at it from modelling. If the code’s concepts do not match the domain’s concepts, every change requires a mapping exercise, and the mapping is where defects breed.

BDD arrives at it from communication. If a scenario is not written in the words the business uses, the business cannot review it, and an unreviewable example has lost the only property that made it worth writing.

The requirement is the same from both directions, which is why Dan North’s founding description of BDD names domain driven design as one of the two strands it brings together, alongside test driven development.

What BDD does not take

Most of domain driven design. Aggregates, entities, value objects, repositories, anti-corruption layers: all useful in a genuinely complex domain, all unnecessary weight in a simple one, and none of them required to practise BDD.

This matters because the pairing is sometimes presented as a package, which puts teams off both. A team can write examples in the business’s language and get the whole benefit of BDD without ever drawing an aggregate boundary.

Where bounded contexts earn their place

The one piece of the heavier machinery that repays attention early is the bounded context, because it names a limit BDD runs into on its own.

A shared vocabulary is achievable inside a bounded area and not across a whole organisation. Sales and fulfilment genuinely mean different things by “order”, and a single definition imposed on both will fit neither. The domain driven design answer is to let each context keep its own language and make the translation at the boundary explicit and owned.

For BDD that translates into a practical rule: write scenarios within one context, in that context’s words, and be suspicious of any scenario whose steps span two. Those scenarios tend to be the ones nobody can agree on, and the disagreement is usually the boundary making itself felt.

Where the pairing gets oversold

The two practices are so often bundled that teams sometimes conclude they need a modelling initiative before they can write a scenario. They do not, and the belief is expensive: it turns a change that could start next Tuesday into a project that needs approval.

The dependency runs one way only. BDD needs a shared vocabulary, which is one chapter of domain driven design. Domain driven design does not need BDD at all, and plenty of teams practise it with conventional tests.

A reasonable order for a team with neither is to start with the examples. Writing them surfaces the vocabulary disagreements immediately, and those disagreements are the raw material a domain model is built from. Teams that go the other way, modelling first, tend to produce a diagram that survives until the first concrete case contradicts it.

What a shared vocabulary costs to maintain

More than it appears, and the cost is renaming. A term that settles differently after a conversation has to be changed in the scenarios, the step definitions, the code and the conversation itself, and the last of those is the one that slips.

Teams that keep a ubiquitous language working treat renaming as ordinary work rather than as a refactor needing justification. Where a rename has to be argued for, the code and the business drift apart one unargued term at a time, and after a year there are two vocabularies again with nobody having decided to have two.