Does DI mechanics break The Dependency Rule?

[lhaze]

Moved here from: #20 (comment)

The quote bellow was originally posted by @ms-lolo and the title of the topic is mine.

Uncle Bob describes the "wiring" of dependencies as a responsibility of "main" (application). If "main" belongs to the outer circles of the clean architecture, and use cases (interactors) belong to an inner circle, shouldn't it be disallowed to have MyInteractor know about the concept of Inject()? You seem to be creating a dependency from an inner circle (the interactor) to an outer one (the di container) which breaks the dependency rule. Would love to know what you folks think about this use. Did I misread the example code?

The Dependency rule, mentioned above, can be stated as

Source code dependencies must point only inward, toward higher-level policies.

and can be described as in The Book.

[lhaze]

Let's split the question:

The application level is responsible for the "wiring" of dependencies.

I would say that an “integration” level is responsible for the “wiring”. An application level is a bunch of use-cases and services, at least IMHO. These are beings that should be runnable and testable without the wiring, just like the domain. Integration level (aka External Interfaces aka Frameworks & Drivers, the blue circle) is the sphere of the runtime that relates dependency points (Inject()) to the actual implementation.

Shouldn't it be disallowed to have MyInteractor know about the concept of Inject()? You seem to be creating a dependency from an inner circle (the interactor) to an outer one (the DI container) which breaks the dependency rule.

Before I say anything about Inject/inject mechanics, let's clarify a common misconception, even if that's not what you have meant. The Dependency Rule doesn't forbid a relation from an inner circle to an outer circle. A domain concept, like an aggregate, can relate to a framework concept like i.e. mailing service. It's a common-sense case: so called an outbound port in the Hexagonal Architecture. The Rule states just the thing that the mentioned aggregate cannot depend on an implementation. It has to know only as much as a common interface/typing.Protocol under the control of the domain circle: an interface that doesn't know implementation details. Quite obvious, right?

When it comes to runtime, the implementation of the dependency has to be delivered to the aggregate. There are some different patterns of delivery. A quite common is by call args. If a function depends on a framework service, it takes it from an arg, but types it as its own interface:

# domain layer
class MailerInterface: ...


def my_function(dependency: MailerInterface) -> ...:
    ...


# framework layer
class MailerService(MailerInterface):
    # MailerInterface can be inherited, but it can be a subclass of typing.Protocol type
    # and there's no need for inheritance


# "integration" layer
my_function(dependency=MailerService())

... but if there are more dependencies, and you have to carry them around from a function call to another function call, it can be quite arduous. Different programming styles have different solutions. Functional programming can solve the problem with Monads. Many Python styles use double star operator (aka double splat operator aka **kwargs) and the strategy of taking an argument one by one, when they are needed, can serve similar purposes. And the last possibility is to gather them into one specific argument. And this is just the moment when DI Container comes into the spotlight.

I find DI container (and the whole dependency mechanics) to be circle-agnostic. If you consider the role of the DI container to the whole system, there's nothing special about it. It wires interfaces with the implementation, across all levels.

For a functional dependency, the Inject object is just a marker without any special mechanics. Wiring is happening outside the function, in the inject decorator. For an attribute dependency, yes, much is happening on the access to the Inject as a descriptor.

Now, back to your question. Shouldn't it be disallowed to have MyInteractor know about the concept of Inject()? I think the most reasonable answer to be “I assume no, but it may depend on a point of view”. I find DI container (and the whole dependency mechanics) to be circle-agnostic. If you consider the role of the DI container to the whole system, there's nothing special about it. It isn't related either to the domain (aka enterprise business rules) — obviously — nor to the application layer (no actual relation to a specific “functionality”/use-case/interactor in the system). It isn't related to the interface adapters layer (obviously, again, it doesn't adapt anything). The only one I would consider, is the frameworks & drivers layer (the blue one), but I am pragmatical about it: frameworks & drivers are about connecting to the external word, whatever that means in the application. Empty DI container doesn't connect anything.

And now to the main point: DI container collects (& hides details of) bindings between interfaces and the implementations. IMO the Dependency Principle is about what depending on (i.e. being controlled by) the outer world. This has little to do with the inner code calling the implementation.