Loading content
Dependency injection is a design pattern that decouples components by providing their dependencies from the outside. It improves testability, modularity and reuse by separating object creation and configuration from business logic. Lifecycle management, dependency scopes and increased indirection should be considered when applying the pattern.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What you need to understand to reason about a domain.
Dependency Injection is a design pattern in which a component receives the dependencies it needs from the outside instead of creating them itself. This separates object creation and configuration from use.
The pattern emerged in object-oriented software engineering from the practical problem that tightly coupled classes and functions are hard to swap and test. In the context of inversion of control and lightweight containers, external provision of dependencies became a common way to separate wiring from use; Martin Fowler’s 2004 article made Dependency Injection widely recognizable as the term for that approach. The motivating issue is modular systems that need configurable, testable composition.
Think of DI as an architectural power strip: the component exposes only the plugs it accepts. An external injector performs the wiring, selects concrete implementations, and passes them in, usually through the constructor. That keeps business logic independent while variability such as database access, logging, or HTTP clients lives in the composition layer.
A required service, object, or function that the component does not create itself.
The external part that provides concrete implementations and assembles object graphs.
Mandatory dependencies are passed when the object is created, making them visible early.
Consumer code depends on a contract or interface rather than a concrete class.
The environment decides when instances are created, shared, or rebuilt.
DI is useful when components should remain replaceable, different environments need different implementations, or tests should substitute real infrastructure with doubles. It is especially valuable in medium to large applications with clear interfaces. For small programs, the extra indirection can add unnecessary complexity, configuration overhead, and stronger framework dependence.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.