BDD advocates for outside-in development because having a clear goal for your code helps you avoid getting bogged down in unnecessary details. It is usually mentioned in the same breath as DDD, but I’m having trouble reconciling the two. DDD urges you to build out your core domain independently of infrastructural concerns so you can focus on what matters most to your business, but how can you do that when outside-in tests will only pass after those concerns are implemented?

Let me give an example. I’m working on an app where writers can answer each other’s prompts/premises. For the MVP, the basic workflow looks like this:

1. Sign in.
2. Create a prompt that you want someone else to write for you.
3. Browse through other people’s prompts in search of ones you want to answer and request an exchange.
4. The other users will be alerted about the request, e.g. through email.
5. The first to accept initiates an exchange, and now both users have until some deadline to writes short stories for each other.
6. Submissions will be rewarded, while failure will be penalized.

To start with, I wrote an API test that covers Points 1 through 3. But even that much requires some form of storage for user accounts and prompts. I’ve got to implement the web layer and the persistence layer at the same time as my domain logic. At that point, why even bother separating the persistence mechanism from the domain layer using, say, abstract repositories, as DDD advises?