DI is really just a means to an end: loose communication . This is a way to provide a free connection by introducing interfaces (or base classes) into consumers so that you can vary independently of each other.
As a rule, nothing happens by entering a specific type . You cannot change the type of another type, so the main advantage of DI is lost.
You can argue that this means that you simply create specific instances from within consumers, but the best alternative is to extract the interfaces from these types (and then introduce them).
And no: itβs never suitable to pull a domain model from inside a container. This is an Anti Locator service pattern template . The Hollywood principle also applies here:
Do not call the container; he will call you
(However, even with a particular type, there are some minor benefits of injecting it. If it is not sealed and has one or more virtual members, you can still cancel its behavior, and even if it is closed, you can still control your life, if you introduce it, for example, you can use the same instance between several consumers, however, these advantages are purely secondary, and usually this is not the main reason why we decided to introduce something.)
Another question (and one that you seem to be really asking) is whether it is advisable to implement services only to transfer them to other services. No, this is not so, since it violates the principle of single responsibility and leads to the constructor of Over-Injection .
It is better to wrap a fine-grained service in larger-grained services. I call these Aggregate Services or Abstract Facades . Although they themselves will have dependencies (for example, the mentioned service endpoints), this will be implementation details . From the point of view of the top-level consumer, they do not exist.
Not only does this solve the problem perfectly around too many dependencies in the constructor, it also helps you better isolate between application tiers.