TDD is no replacement for good design and architecture. I shouldn’t have to say this, but the more I read about TDD, the more I see people saying they aren’t sold on it, because even when they use it they discover their app is designed wrong for the actual requirements, and now they have to tear it apart and start over.
This is not the fault of TDD.
TDD should be irrelevant to your design process. The only demand TDD puts on your design is the same demand any testing-heavy process would: extensive use of dependency injection to make unit testing with mocks easier. You should already have architected your module to match your requirements, before you ever write one line of code. Take the time to do your design in a deep way, before you start coding, and you will save yourself much time later.
TDD is not there to make your design better or to show you where your architecture needs to be rethought. TDD is there to ensure as you go that you are fulfilling the plan you already came up with, and not introducing other factors. TDD is a check, not a solution. Use it right, and you will reap the benefits of more stable code, more reliable extensibility, and fewer bugs getting to your users. Just don’t expect it to do your work for you.