How to practice TDD within a DDD project?

[Mik Wings7]

TDD is about designing code, guided by tests.
Thus, typical layers aren't usually built upfront; they should slightly appear through refactoring steps.

Domain-driven design involves a lot of technical patterns, defining well established layers like Application layer, Infrastructure layer, Domain Layer, Persistence layer.

To start a DDD project's coding part from scratch, how to behave?
Should I strictly let design emerge from tests, meaning no separation of concerns (no layers) and refactor in order to fit DDD technical patterns? 

Or should I create those empty layers (application, entities/domain services, infrastructure) and let TDD fit in each of them independently (using sometimes mocks)?

[Norbert Nemes]

That's a togh one. If you watch Uncle Bob's Java case study, they went by doing TDD first and refactored it later into the clean architecture. On my project I decided upon the layers and TDD-ed the interfaces and collaborators. I guess it works either way :)