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)?

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 mocks to isolate between layers)?

TDD is about designing code, guided by tests.
Thus, typical layers aren't usually built upfront; they should appear slightly 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)?

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)?