DDD, BDD and other Pokémon
Context must come before methodology: first understand WHAT and WHY you're building something, then consider applying specialized approaches like DDD or TDD.
Technical freaks and trend followers want to apply DDD, BDD, FDD, TDD, or other "Pokemons" everywhere. Instead of focusing on trends and implementing new great approaches to problems that were solved long ago, the team should first start by figuring out WHAT and WHY they are doing THIS.
First, the team must understand the business, the company's situation, project requirements, and stakeholder expectations. Only then comes the time to employ the mentioned list of Pokemons full-time.
There's no value in the team switching to writing code in TDD style and implementing DDD patterns if they're clueless about the fundamental understanding of why they're doing it. Especially if the domain is complex. Finding this out answers and understanding is difficult but required.
The team needs to know the context, then understand the context, and finally hire a Pokemon for its services.
~KB
Krzysztof Baranowski