I'll be using Uncle Bob's terms, so i'll call the use cases "interactors" and the domain entities "entities". As far as I understand, the most specific business rules that are most likely to change should not be in the domain entities, but in the application layer (in the interactors). And the business rules that are less likely to change (unless there is a foundational change to that entity) should go in the domain (in the entities).
So, I did some TDD kata's and watched several TDD demo's and conferences about TDD, and it is a discipline that I would like to incorporate into my development skills. But i'm having a hard time trying to combine TDD with clean architerture, i think there is something i am not understanding well enough. I don't really know if TDD has to fit into a clean architecture or let the clean architecture emerge from the TDD (maybe in the refactor phase). Am I explaining myself enough?
Just to give some context, imagine you start a web app project from scratch. What should you test? What should be the first test that you would do, an interactor test? A domain entity test? Should your entities emerge from tdding the interactors? Do I have to know upfront if what I am testing is a use case or an entity? Or should I just focus on the business rule being satisfied regardless of whether the logic I'm testing goes to the entity or the interactor?
In other words, should you start by applying TDD to the interactor business logic or should you start TDDing the business logic in the domain entities?
I hope someone can bring me some light to this issue.