Clean Architecture - Should you inject all entity dependencies?

Question

According to "Clean Architecture", should you inject all entity dependencies (should you inject core business logic)?

For example, if I have a vector entity, should that entity be injected into all other entities/use cases or should the entities/use cases depend on vector directly?

In one way, it makes sense to inject vector because in theory you could have different implementations that might be faster for example.

But on the other hand, if you did have a faster implementation, you would probably want to use it everywhere, rather than mixing implementations in the codebase. This means depending directly on vector would make sense.

To prevent this question from being subjective, is there an exact answer to this question according to "Clean Architecture"? Or is this question entirely opinion-based?

Answer 1

Inject across boundaries. Hard coding matters for testing but mocking frameworks and reflection magic can take care of that. The critical boundary is deployment.

If you want units of code to be independently deployable they can't have hard coded dependencies on each other. If you want to change a classes name it sucks if the refactoring reaches into code that you don't control with this deployment. Depending on code you can't force to recompile sets your code in cement.

Clean Architecture wants it's onion "layers" to be independently deployable. So no hard coding across them. Outer layers are at the mercy of the inner layers so outer layers can "know" about the inner layers but also know that they don't control the inner layers interfaces. If those interfaces change it breaks the outer layers which must update. But so long as the interfaces stay the same each layer, inner or outer, can be independently deployed.

You are free to hard code within them, or not. That's between you, your team, and your testing framework.