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?
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.-- Why do you say that? DDD is a way to model software against business processes using an ubiquitous language (a language that the software engineer and business analyst can both understand and communicate with), so it impacts directly and profoundly on the software requirements.