Hi Fernando!! Thanks for the question!

I think the first important point is to have your classes that uses this Network depending upon a Network abstraction (a protocol in your case). This is thinking in DIP.

Now about where we should create this protocol, I think it depends. In theory it would be nice to have a module for your Network concrete implementation, another module with only your interfaces for this Network (NetworkInterfaceModule for instance), and then your app, that uses from both. Your app would have their structures depending upon the abstraction, but it would inject the concrete implementation.

This will be the best option IMO, because you wouldn't be coupling the Network, and you'd be able to throw away this concrete implementation and substitute it by another one, without changing the app at all.

In the practice however, it may be considered a kind of boilerplate, having a module with only some interfaces/protocols. So, I wouldn't see as not respecting the DIP letting the protocol on the Network module. You'd only lose this advantage I've mentioned above, which is not something totally bad, since it's really rare having to substitute a whole module in a project. And when it happens, it's really hard to keep the protocol contracts. So, in those cases, having this new module would be a boilerplate and an unnecessary complexity in your project.

Finally, why would I let this in the same Network module instead of the app? Because the Network module's owner probably will implement unit and integration tests on its module for the Network they built. The protocol probably will be needed to make this happen. Also, you definitely will need to use the Network in other modules inside your app, and you won't want to create a new Protocol every time you need it.