golang-dependency-injection

Pass dependencies through constructors like NewUserService(db, mailer, logger) and wire them explicitly in main(). For small projects under 10 services, manual constructor injection is sufficient; larger projects benefit from a DI library.

google/wire offers compile-time safety via code generation but no lifecycle management. uber-go/fx provides full lifecycle hooks but uses reflection. samber/do gives compile-time generics safety with built-in health checks and shutdown, requiring Go 1.18+.

Stay with manual constructor injection for projects under 10 services. Consider a library at 10-20 services with cross-cutting concerns, and strongly adopt one beyond 20 services or when you need health checks, graceful shutdown, or lazy loading.

Passing the container into services is the service locator anti-pattern, hiding real dependencies and making testing harder. The container should exist only at the composition root in main(), with services receiving specific dependencies via constructors.

Define a mock implementing the consumer-side interface and inject it through the constructor in tests. With samber/do, clone the container and use do.OverrideValue to replace only the boundary services like databases or mailers.

No. Wire generates plain Go constructor calls with all dependencies created eagerly and no built-in health checks or shutdown hooks. Cleanup relies on functions returned from providers, while fx and samber/do offer built-in lifecycle support.