golang-dependency-injection

Guide Go developers in implementing constructor-based dependency injection with interfaces at consumer boundaries.

4|Updated May 17, 2026
One-click install
npx skills add https://github.com/hellopoisonx/aim --skill golang-dependency-injection-hellopoisonx
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: golang-dependency-injection
Source: https://github.com/hellopoisonx/aim/tree/main/skills/golang-dependency-injection
Command: npx skills add https://github.com/hellopoisonx/aim --skill golang-dependency-injection-hellopoisonx

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps you design and refactor Go code so dependencies are explicit, lifecycle-safe, and easy to test instead of being hidden in globals or init-time side effects.

Core Features & Use Cases

  • Constructor injection only: Dependencies are passed into components via constructors to keep wiring explicit and testable.
  • Interface-at-consumer boundary: Interfaces are defined where they are consumed, enabling flexible implementations without tight coupling.
  • No service-locator anti-patterns: Containers/injectors exist only at the composition root, never injected into business services.
  • Library selection guidance: Chooses between manual DI, google/wire, uber-go/dig+fx, and samber/do based on project size and lifecycle needs.
  • Refactor workflow for coupled code: Identifies globals, init setup, and container misuse, then provides a migration plan.

Quick Start

Ask the AI to redesign your service so it uses constructor injection, defines needed interfaces at the consumption sites, and wires everything at main() (or app startup) without globals or init-based setup.

Frequently Asked Questions about golang-dependency-injection

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement dependency injection in Go to make services testable?

Pass dependencies via constructors and define interfaces at the consumption boundary, wiring everything explicitly at the composition root to keep Go services testable and lifecycle-safe without hidden globals.

What is the difference between google/wire and samber/do for Go service lifecycle management?

google/wire generates compile-time wiring code for static safety, whereas samber/do provides a runtime container with lifecycle hooks, making them suited for different project scales and dynamic lifecycle management needs.

How do I refactor coupled Go code that uses global state and init-time side effects?

Identify globals, init setup, and container misuse, then migrate to constructor-based injection by moving dependency wiring to the application composition root and defining required interfaces at the consumer boundary.

When should I avoid the service-locator pattern in Go dependency injection?

Avoid the service-locator pattern whenever containers or injectors are passed into business services, restricting containers strictly to the composition root to prevent hidden dependencies and maintain explicit wiring.

Does constructor injection work with lifecycle-managed Go microservices?

Yes, constructor injection provides the explicit wiring foundation, while frameworks like uber-go/dig+fx or samber/do can manage the lifecycle layer on top, ensuring services remain testable and decoupled in microservice architectures.