I like the middle-out development that is achieved with DDD. Development is driven by domain, the most solid part of application. We don\'t depend on infrastructure, persistence
I can't see why it shouldn't work? BDD is behavior driven development, that is, aboout your development process, which could (should) impact your design. DDD is domain driven design and is more about the overall design of your system. To make a long story short, in BDD (or any other xDD) you define how something should work and then it is up to your domain to realize those requirements. If you implement those requirements using DDD or something else shouldn't matter... you still need a green mark next to that test.
UPDATE: I don't think DDD is about direction, for me DDD is about keeping your code clean. I would say that using BDD is a way to help keeping your code clean, if you start with just implementing your domain you might end up with a domain that is too complex. The way I would like to do it is to use BDD to define my features (like log in functionality) and different scenarios (like successful and unsuccessful log in). After that I wouldn't write some unit tests so I have something that test the code and not the behavior. When I have implemented so the unit tests pass hopefully the BDD test pass as well. After that it is time for refactoring and during the refactoring all your tests should stay green. You can see it as two cycles, an outer cycle that tests the behavior (BDD) and one inner circle that tests the implementation (TDD). This should not stop you from using DDD principles, instead I would say it would make it easier to keep your domain clean and solving your actual problem at hand.
Update 2 (links):