We are only writing unit tests for Business Logic layer and mocking other parts. Is it possible and reasonable to do TDD in this case?
Yes, in fact that is highly recommended over the "unit test everything" attitude.
Remember, business logic is the interesting stuff that makes decisions. Everything else is just boring infrastructure code that wires up connections.
The boring infrastructure is easy to read but hard to test. The point of tests is to make code easy for humans to read. Boring easy to read code doesn't need unit tests.
This is why we don't unit tests GUI's. Instead we move all interesting logic out of the GUI and put it someplace testable.
The name for seperating hard to test code from interesting code is The Humble Object pattern1,2
TDD works best when you follow this pattern. It basically says if your code is interesting and hard to test then separate the interesting stuff from the hard to test stuff. That can be as simple as turning one function into two. One you unit test. One you don't.
Thinking you have to unit test everything in TDD is quick way to convince people that TDD doesn't work. No that's not what it's for.
Keep in mind there are many other kinds of tests besides unit tests.
The slow ones are sometimes called integration tests. That's when you test what happens when you connect the things that TDD isolates. Those tests mostly just show that the connections work. These tests are slow. You don't run them often. Just be sure you run them at least once before you publish.
TDD is about the really fast tests. So fast you run them every time you compile. Some people run them on every keystroke.3 So please, don't confuse these two different kinds of tests and blame the resulting nightmare on TDD. That's not its fault.
Use TDD on what it's for: the interesting stuff.