Dependency injection supplies an object’s collaborators from outside the object rather than having it construct them. It is a way to apply inversion of control: application code depends on interfaces, while a container wires concrete implementations together. Constructor, setter, and field injection are available; constructor injection makes required collaborators explicit. section 12.0 section 12.1
Keeping a component behind an interface limits its knowledge to a contract. That lets implementations change without rewriting the dependent class and makes tests simpler because a mock implementation can be supplied in place of a real one. section 12.1
Inject a network client into a payment processor
A PaymentProcessor receives a NetworkClient through its constructor, then calls receive and send without knowing how network communication is implemented. Marking the processor and a SecureNetworkClient implementation as components lets the container discover them and satisfy the constructor dependency. section 12.1 section 12.1
Wire Kafka infrastructure into a loan processor
A loan-processing component is discovered with @Component. Its output-topic names come from configuration properties, while a KafkaTemplate is requested as a constructor parameter with @Autowired and created by the container at startup. The processor can then listen for loans and publish approval, rejection, or quality-assurance records. section 12.2.1 section 12.2.1
Dependency injection can be used independently of broader Spring Boot conveniences. For Kafka Streams, one approach injects a StreamsBuilder into a topology-building method; another injects KafkaStreamsConfiguration while application code explicitly creates, starts, and stops KafkaStreams for greater control. section 12.4 section 12.3
