Persona: あなたは依存性注入を設定する Go アーキテクトです。コンテナを構成ルートに保ち、具象型ではなくインターフェースに依存し、プロバイダーエラーを第一級の失敗として扱います。

Go での samber/do による依存性注入

Go 1.18+ ジェネリクスに基づく型安全な依存性注入ツールキット。

公式リソース:

• pkg.go.dev/github.com/samber/do/v2
• do.samber.dev
• github.com/samber/do/v2

このスキルはすべてをカバーしていません。詳細についてはライブラリドキュメントとコード例を参照してください。Context7 は検出可能性プラットフォームとして役立ちます。

このライブラリの v1 を使用しないでください。代わりに v2 をインストールしてください:

go get -u github.com/samber/do/v2

コアコンセプト

Injector (コンテナ)

import "github.com/samber/do/v2"

injector := do.New()

サービスタイプ

• Lazy (デフォルト): 最初にリクエストされたときに作成
• Eager: コンテナ開始時に即座に作成
• Transient: リクエストのたびに新しいインスタンスを作成
• Value: 事前作成された値、インスタンス化なし

プロバイダー関数

サービスはプロバイダー関数経由で登録する必要があります:

type Provider[T any] func(i Injector) (T, error)

基本的な使用方法

1. サービスの定義と登録

「インターフェースを受け取り、構造体を返す」に従う:

// サービスを登録 (デフォルトは遅延)
do.Provide(injector, func(i do.Injector) (Database, error) {
    return &PostgreSQLDatabase{connString: "postgres://..."}, nil
})

// 事前作成された値を登録
do.ProvideValue(injector, &Config{Port: 8080})

// トランジェントサービスを登録 (毎回新しいインスタンス)
do.ProvideTransient(injector, func(i do.Injector) (*Logger, error) {
    return &Logger{}, nil
})

// Eager サービスを登録 (即座に作成)
do.Provide(injector, do.Eager(&Config{Port: 8080}))

2. サービスの呼び出し

コンテナは構成ルートでのみアクセスする必要があります:

// エラーハンドリング付きで呼び出し
db, err := do.Invoke[Database](injector)

// MustInvoke はエラー時にパニック (サービスが存在することが確実な場合に使用)
db := do.MustInvoke[Database](injector)

3. サービスの依存関係

func NewUserService(i do.Injector) (UserService, error) {
    db := do.MustInvoke[Database](i)
    cache := do.MustInvoke[Cache](i)
    return &userService{db: db, cache: cache}, nil
}

do.Provide(injector, NewUserService)

4. 暗黙的エイリアシング (推奨)

具象型を登録し、明示的なエイリアシングなしでインターフェースとして呼び出す:

// 具象型を登録
do.Provide(injector, func(i do.Injector) (*PostgreSQLDatabase, error) {
    return &PostgreSQLDatabase{}, nil
})

// インターフェースとして直接呼び出す (暗黙的エイリアシング)
db := do.MustInvokeAs[Database](injector)

5. 名前付きサービス

同じ型の複数のサービスを登録:

do.ProvideNamed(injector, "primary-db", func(i do.Injector) (*Database, error) {
    return &Database{URL: "postgres://primary..."}, nil
})

mainDB := do.MustInvokeNamed[*Database](injector, "primary-db")

パッケージ構成

do.Package() を使ってモジュール別にサービス登録を整理:

// infrastructure/package.go
var Package = do.Package(
    do.Lazy(func(i do.Injector) (*postgres.DB, error) {
        cfg := do.MustInvoke[*Config](i)
        return postgres.Connect(cfg.DatabaseURL)
    }),
    do.Lazy(func(i do.Injector) (*redis.Client, error) {
        cfg := do.MustInvoke[*Config](i)
        return redis.NewClient(cfg.RedisURL), nil
    }),
)

// main.go
injector := do.New(infrastructure.Package, service.Package)

完全なアプリケーション設定

func main() {
    injector := do.New(
        infrastructure.Package,
        repository.Package,
        service.Package,
        transport.Package,
    )

    server := do.MustInvoke[*http.Server](injector)
    go server.ListenAndServe()

    _ = injector.ShutdownOnSignalsWithContext(context.Background(), os.Interrupt)
}

ベストプラクティス

1. 具象型ではなくインターフェースに依存する — テストで本番コードに触れることなく実装を入れ替えられます
2. 各サービスは 1 つの役目を持つ — 複数の責務を持つサービスはテストが難しく、置き換えも困難です
3. 依存関係の木を浅く保つ — 3-4 レベルを超える連鎖は初期化順序を不安定にし、エラー追跡を困難にします
4. プロバイダー関数でエラーを処理する — サイレントに失敗するプロバイダーは壊れたサービスを作成し、予期しない場所でクラッシュします
5. スコープを使ってライフサイクル別にサービスを整理する — リクエストスコープサービスはリークを防ぎ、グローバルサービスは冗長な初期化を防ぎます

スコープ、ライフサイクル管理、構造体インジェクション、デバッグについては Advanced Usage を参照してください。

テストパターン (クローン、オーバーライド、モック) については Testing を参照してください。

クイックリファレンス

登録

関数	目的
do.Provide[T]()	遅延サービスを登録 (デフォルト)
do.ProvideNamed[T]()	名前付き遅延サービスを登録
do.ProvideValue[T]()	事前作成値を登録
do.ProvideNamedValue[T]()	名前付き値を登録
do.ProvideTransient[T]()	毎回新しいインスタンスを登録
do.ProvideNamedTransient[T]()	名前付きトランジェントを登録
do.Package()	サービス登録をグループ化

呼び出し

関数	目的
do.Invoke[T]()	サービスを取得 (エラー付き)
do.InvokeNamed[T]()	名前付きサービスを取得
do.InvokeAs[T]()	インターフェースに一致する最初のサービスを取得
do.InvokeStruct[T]()	タグを使ってサービスを構造体フィールドに注入
do.MustInvoke[T]()	サービスを取得 (エラーでパニック)
do.MustInvokeNamed[T]()	名前付きサービスを取得 (エラーでパニック)
do.MustInvokeAs[T]()	インターフェースでサービスを取得 (エラーでパニック)
do.MustInvokeStruct[T]()	サービスを構造体に注入 (エラーでパニック)

クロスリファレンス

• → DI コンセプト、比較、DI ライブラリを採用するタイミングについては samber/cc-skills-golang@golang-dependency-injection スキルを参照してください
• → インターフェース設計パターンについては samber/cc-skills-golang@golang-structs-interfaces スキルを参照してください
• → 一般的なテストパターンについては samber/cc-skills-golang@golang-testing スキルを参照してください