The simplest answer I know of is to separate the bits that consume the data from the bits that provide the data.
The bit that knows about the application specific business rules is just an in memory state machine -- aka an "object" -- with a data interface.
Separate from that is the protocol, the bit of logic that understands how to move the data from one place to another. This is the bit of code that coordinates the flow of data between the different dependencies. In other words, this code knows how to route the data from one place to another, but doesn't usually need to inspect the data.
So you test the application specific business rules by instantiating the object in your test, and passing data to it directly.
You test the protocol by using test doubles.
In some cases, the protocol can be broken down into logical units that don't involve all of the dependencies. In that case, you can write tests that focus on the smaller units, with tests that focus on the coordination between a subset of the dependencies, rather than all of them.