In particular, DDD relates more to the modeling of the application domain. In this sense, it can be observed from a more architectural point of view, defining how our application is modularized, the different layers, and even how different parts of our broader application (or, if you wish, different teams) should cooperate.

Once we have designed such layers and components, both TDD and BDD can be used as a way to drive our day-to-day development, ensuring we have the right testability and feature coverage requested within our code.

On the other hand, DDD is not a requirement for TDD or BDD, which can be seen as a simple technique that is also applicable to smaller applications, or to software architectures defined with approaches alternative to DDD. As you will often find in this book, those concepts can be viewed as tools, briefly introduced to give you an idea of their potentiality. It's up to you to then take what's needed for your specific project and combine it in a useful way.