go-dependency-injection

Files (1)

• SKILL.md

SKILL.md (first lines)

# Go Dependency Injection

DI in Go is a pattern, not a framework: pass dependencies to
constructors, wire everything explicitly in `main`. Reach for a
framework only when manual wiring measurably hurts.

> Community default. A project skill or agent-config rule that explicitly
> supersedes `go-dependency-injection` takes precedence over this one.

## 1. Constructor Injection — the Default

```go
// ✅ Good — dependencies are explicit parameters
type OrderService struct {
    repo     OrderRepository
    payments PaymentGateway
    logger   *slog.Logger
}

func NewOrderService(repo OrderRepository, payments PaymentGateway, logger *slog.Logger) *OrderService {
    return &OrderService{repo: repo, payments: payments, logger: logger}
}

// ❌ Bad — hidden dependencies reached through globals
func (s *OrderService) Place(ctx context.Context, o Order) error {
    db := database.Get()        // global singleton
    log.Printf("placing order") // global logger
    // untestable without touching process-wide state
}
```

Rules:

- Accept interfaces for dependencies the service calls; return the
  concrete type from the constructor.
- Every dependency visible in the signature — if the list feels long,
  the type does too much (split it), don't hide deps to shorten it.
- Validate required deps in the constructor and return an error
  (or accept a nil-safe default, e.g. `logger = slog.Default()`).

## 2. The Composition Root

All wiring lives in one place — `main` (or a `run` function it calls).
Construction order is the dependency order, checked by the compiler:

```go
func run(ctx context.Context, cfg Config) error {
    db, err := store.Open(ctx, cfg.DatabaseURL)
    if err != nil {
        return fmt.Errorf("open db: %w", err)
    }
    defer db.Close()

    orderRepo := store.NewOrderRepo(db)
    payments := stripe.NewGateway(cfg.StripeKey)
    logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))

    orders := service.NewOrderService(orderRepo, payments, logger)
    server := handler.NewServer(cfg.Addr, orders)

    return server.ListenAndServe(ctx)
}
```

- No package builds its own dependencies; it receives them.
- No `init()` wiring, no package-level `var DB *sql.DB`.
- Two binaries needing different wiring = two mains, same components.

## 3. Eliminating Global State

```go
// ❌ Before — package-level singleton
var defaultClient *api.Client

func Fetch(id string) (*Item, error) {
    return defaultClient.Get(id)
}

// ✅ After — the dependency moves into a struct
type Fetcher struct {
    client *api.Client
}

func NewFetcher(c *api.Client) *Fetcher { return &Fetcher{client: c} }

func (f *Fetcher) Fetch(id string) (*Item, error) {
    return f.client.Get(id)
}
```

Migration path for a legacy codebase: introduce the struct, keep a
deprecated package-level wrapper delegating to one instance built in
`main`, move callers over, delete the wrapper.

Acceptable package-level state: pure constants, compiled regexps,
`sync.Once`-guarded process singletons that hold no config.

## 4. Function Dependencies for Small Seams

A full interface is overkill for one function — inject the function:

```go
type Service struct {
    now     func() time.Time
    genID   func() string
    publish func(ctx context.Context, e Event) error
}

// Production: Service{now: time.Now, genID: uuid.NewString, publish: bus.Publish}
// Test:       Service{now: fixedTime, genID: constID, publish: capture}
```

## 5. When Frameworks Earn Their Complexity

Manual wiring scales further than expected — a 100-line `run` function
is still readable and compiler-checked. Consider a tool when wiring
crosses hundreds of components or many teams share one binary.

| Tool | Model | Trade-off |

From eduardo-sl/go-agent-skills, MIT.

More from eduardo-sl/go-agent-skills