Dependency Injection

Passing dependencies to a component from the outside instead of letting it create them internally.

Dependency Injection means passing dependencies (like repositories, API clients, or services) into a component rather than having the component create them itself. The component declares what it needs, and the caller provides concrete implementations.

In Go, this typically looks like a constructor that accepts interfaces:

type OrderRepository interface {
    Save(order Order) error
    FindByID(id string) (Order, error)
}

type PaymentGateway interface {
    Charge(amount Money, card Card) error
}

func NewOrderService(
    repo OrderRepository,
    payments PaymentGateway,
) OrderService {
    return OrderService{
        repo:     repo,
        payments: payments,
    }
}

The OrderService doesn't know if repo talks to PostgreSQL, Firestore, or an in-memory map. It works with the interface. The main function (or a setup function) decides which implementation to use and wires everything together.

This is the foundation of Clean Architecture. The Dependency Inversion Principle says that high-level modules shouldn't depend on low-level modules, but on abstractions. Dependency injection is how you put that principle into practice: you define interfaces in the application layer and inject implementations from the adapters layer.

The biggest payoff is testability. When your service accepts interfaces, you can pass a mock or an in-memory implementation in tests. You don't need to deal with network calls or flaky infrastructure. Your unit tests become fast and focused on business logic.

In Go, you don't need a framework for this. The simplest approach is to wire everything manually in main.go. It's explicit, easy to follow, and the compiler tells you immediately if something is missing. The wiring code can grow large in bigger projects, but it's straightforward to maintain.

Some teams use code generation or reflection-based tools to reduce boilerplate. Manual wiring is more verbose, but you can read the code and understand exactly what's happening. With reflection-based tools, debugging gets harder because the dependency graph is resolved at runtime.

The trade-off is boilerplate. You need constructors, interfaces, and explicit wiring code. For small projects, this can feel like overhead. As the codebase grows and more people contribute, it quickly pays off.