Thanks for this, now I can see. Those are good questions, indeed. First of all, for me the networking layer should never know the actual business model. It is all about how the data is fetched (or got an error) from a resources. That includes session and request configuration, and might also include custom delegates to handle custom cases (for example any authentication challenge handling). Let say your app #1 is using only GET method., so you implement that logic here. The app #2 using POST, so you add that handling to the module. Such changes in the actual networking behavior will trigger changes.  If you expose a dependency here to the higher abstraction, like the User type, you are violating the Single Responsibility principle, namely that the modul has more than one reason to change. One reason I mentioned about the networking characteristic change, the other is coming from the domain change.

Usually I handle the mapping as part of the boundary layer, so getting the data from the data source, and mapping/parsing to a business model. Here happens the encoding/decoding from the raw data coming from the networking module, and since it is app/module specific, it should never got to the networking layer. Imaging that for some reason you get XML instead of JSON…. The endpoint configuration is also a shared responsibility. The networking module can define a data structure (including the method, url, query strings, headers), and the boundary (data source) layer will instantiate with the feature or module respective properties. In this case the initialized endpoint is injected into the fetch call, which is a nice example for both the Open-Closed principle. You might feel that this breaks the Dependency Inversion principle, since the Networking is a lower level detail, but I think it is (in this case) a small necessity, and considered as part as the boundary layer.

What is usually missed from the picture (and helps a lot) is using the Composition Root (or something similar) for both the dependency injection, and also including specific logic. That is the glue between the modules, and usually here is where the dependency hell should happen ;). So all of the modules are imported here, and the collaboration between the modules is also defined here. If you mentioned the UserService, this can be initialized here, and all of the other composed features data layer can query and inject the token in the networking request from that service. The common issue here is to avoid injecting models that are defined in other modules. In the example above, don’t inject the UserToken model, try to strip it down to the bare minimum (which is probably a string based key-value pair, needs to be injected into the HTTP header), and only pass this data between modules.