Does BDD and DDD work well together?

Question

Behavior-Driven Development (BDD) can be described as in this blog post as follows:

Behaviour-driven development (BDD) takes the position that you can turn an idea for a requirement into implemented, tested, production-ready code simply and effectively, as long as the requirement is specific enough that everyone knows what’s going on. To do this, we need a way to describe the requirement such that everyone – the business folks, the analyst, the developer and the tester – have a common understanding of the scope of the work. From this, they can agree to a common definition of “done”, and we escape the dual gumption traps of “that’s not what I asked for” or “I forgot to tell you about this other thing”.

So it seems much like a way to manage the requirements of the software and really have a clear notion of what has to be developed and the criteria of whether or not it has been developed correctly.

Domain-Driven Design, on the other hand, is a modeling effort, which puts the focus on the business rules and the construction of a ubiquitous language. Domain-Driven Design furnishes very nice ideas on how to structure the code, how to break a complex domain into smaller parts (with Bounded Contexts), and how to understand different "types" of objects which might be needed in coding, by defining precisely entities, aggregates, and so forth.

It turns out DDD doesn't tell much (as far as I know), if it tells anything, about how to deal with the requirements of the software.

How to bridge the requirements organization and the notion of what has to be developed, to actually developing it, to the point where DDD becomes useful, it seems that DDD doesn't tell.

Since DDD puts focus on constructing one ubiquitous language which employs the business terms and talks about "really understanding what the domain is and needs", it seemed to me at first that BDD and DDD can go along together nicely.

But this is a matter of experience. The only one who has tried can know the results.

My question here is: has anyone tried using both BDD and DDD together? Is it a correct thing to use then together? If not, why they don't go along contrary to intuition?

Answer 1

Like @robert-harvey already pointed out, the ubiquitous language is ideally the common binding force.

DDD focuses on defining the vocabulary in that language: actors, entities, operations, ... An important part of DDD is also that the ubiquitous language can be clearly seen in the code, too, not only in communication between the implementor and the domain expert. So an extreme view of DDD is quite static: it describes the finished system as a whole.

BDD focuses on defining user stories or scenarios. It is closely related to an incremental process, but it can also be viewed as static: it describes all the interactions between users and the finished system.

DDD and BDD can be applied with no overlapping: BDD user stories can be written using only UI vocabulary (buttons, labels, ...), and DDD can avoid mentioning interactions.

But ideally these two overlap and work together: the BDD stories are rich in the ubiquitous language, describing the user experience with domain concepts. And DDD makes sure the stories can be found in the code.