TypeScript Decoratorで学ぶ！ゼロから作る依存性注入コンテナ

Posted at 2026-08-22

「TypeScriptプロジェクトで依存関係が複雑になり、テストがしにくい」「DIコンテナを導入したいけど、デコレータの使い方がよく分からない」そう感じていませんか？特にTypeScript 5.0以降、デコレータの仕様が標準化され、以前とは異なる書き方に戸惑う方も多いでしょう。

この記事では、TypeScript Decoratorの最新仕様を活用し、DIコンテナをゼロから自作する実践的な手順を解説します。自作を通してDIコンテナの動作原理を深く理解し、InversifyJSやTypeDIといった既存ライブラリの利用法、そして大規模アプリケーション開発における依存性管理のベストプラクティスまでを網羅的に習得できます。読み終える頃には、あなたのTypeScriptアプリケーションはより疎結合でテストしやすい設計になっているはずです。

TypeScript DecoratorとDIコンテナの基本を理解する

このセクションでは、TypeScriptのデコレータと依存性注入（DI）コンテナの基本的な概念、そしてなぜこれらが現代のアプリケーション開発において重要なのかを解説します。

TypeScript Decoratorとは何か？

TypeScriptのデコレータは、クラス、メソッド、プロパティ、アクセサにアノテーション（注釈）を付与し、その構造や振る舞いを変更するための特別な宣言です。簡単に言えば、コードにメタデータ（付加情報）を追加したり、実行時にコードを拡張したりする機能を提供します。

TypeScript 5.0以降のデコレータは、TC39 Stage 3のプロポーザルに準拠しており、以前の--experimentalDecoratorsフラグを必要とするレガシーデコレータとは異なる新しいAPIを持っています。これにより、デコレータは将来的なJavaScript標準としてより安定したものになりました。

例えば、以下のようにクラスにデコレータを適用できます。

function logClass(target: Function, context: ClassDecoratorContext) {
  console.log(`Class ${String(context.name)} was defined.`);
  // クラスの振る舞いを変更するロジックをここに追加
}

@logClass
class MyService {
  constructor() {
    console.log("MyService instance created.");
  }
}

new MyService();
// 出力:
// Class MyService was defined.
// MyService instance created.

依存性注入（DI）コンテナとは何か？

依存性注入（Dependency Injection: DI）は、オブジェクトが依存する他のオブジェクト（依存関係）を、オブジェクト自身が生成するのではなく、外部から注入（提供）する設計パターンです。これにより、オブジェクト間の結合度を下げ、テスト容易性や保守性を向上させます。

DIコンテナ（またはIoCコンテナ: Inversion of Control Container）は、この依存関係の解決とオブジェクトの生成・管理を自動的に行うフレームワークです。アプリケーションの起動時に依存関係を登録し、必要に応じてコンテナからインスタンスを取得することで、複雑な依存関係の解決をコンテナに任せることができます。

DIコンテナのメリット:

疎結合: クラスが具体的な依存関係に直接依存せず、抽象（インターフェース）に依存するようになります。
テスト容易性: ユニットテスト時に、実際の依存関係の代わりにモックオブジェクトを簡単に注入できます。
コードの再利用性: 依存関係の実装を容易に切り替えられるため、共通ロジックの再利用が促進されます。
保守性: 変更が他の部分に与える影響を最小限に抑えられます。

環境セットアップとtsconfig.jsonの重要設定

DIコンテナをTypeScriptで実装する際には、適切な環境設定が不可欠です。特にtsconfig.jsonの設定は、デコレータとreflect-metadataの動作に大きく影響します。

プロジェクトの初期設定

まずは、プロジェクトのディレクトリを作成し、必要なパッケージをインストールします。

# プロジェクト作成
mkdir my-di-container
cd my-di-container
npm init -y

# TypeScriptとreflect-metadataをインストール
npm install typescript reflect-metadata
npm install -D @types/node

# tsconfig.json を生成
npx tsc --init

tsconfig.jsonの重要設定

tsconfig.jsonを開き、以下の項目を追記または変更します。特にexperimentalDecoratorsとemitDecoratorMetadataは、デコレータの挙動に直結するため注意が必要です。

{
  "compilerOptions": {
    "target": "es2022", // またはそれ以降。新しいJS機能を活用
    "module": "commonjs", // またはesnext, node16, nodenext。モジュール解決方法
    "lib": ["es2022", "dom"], // 利用する標準ライブラリ
    "strict": true, // 厳格な型チェックを有効にする
    "esModuleInterop": true, // CommonJSとES Modules間の互換性を向上させる
    "forceConsistentCasingInFileNames": true, // ファイル名の大文字小文字を区別する

    // --- ここが重要: Decoratorとreflect-metadataの設定 ---
    // TypeScript 5.0以降の標準デコレータを使用する場合（自作DIコンテナやTypeDIで利用可能）
    "experimentalDecorators": false, // 標準デコレータを使用するためfalseまたは削除
    "emitDecoratorMetadata": true, // reflect-metadata を使用する場合に必須

    // InversifyJSなど、レガシーなデコレータに依存するライブラリを使用する場合
    // "experimentalDecorators": true, // レガシーデコレータを使用するためtrue
    // "emitDecoratorMetadata": true, // reflect-metadata を使用する場合に必須
    // ---------------------------------------------------

    "moduleResolution": "node", // またはbundler, node16, nodenext
    "outDir": "./dist", // コンパイル出力先
    "rootDir": "./src" // ソースコードのルートディレクトリ
  },
  "include": ["src/**/*.ts"], // コンパイル対象ファイル
  "exclude": ["node_modules"] // コンパイル対象外ファイル
}

ポイント:

"experimentalDecorators": false：TypeScript 5.0以降の標準デコレータを使用する場合、この設定はfalseにするか、削除してください。trueにするとレガシーデコレータの挙動になります。
"emitDecoratorMetadata": true：これはreflect-metadataライブラリと連携し、TypeScriptの型情報（例えば、コンストラクタ引数の型）をデコレータが実行時に利用できるようにするための設定です。DIコンテナの自動解決機能に不可欠です。

ゼロからTypeScript DIコンテナを自作する

このセクションでは、TypeScript 5.0以降のデコレータとreflect-metadataを活用して、シンプルなDIコンテナを自作する手順を解説します。

1. `reflect-metadata`のインポート

reflect-metadataは、アプリケーションのエントリポイントで必ず最初にインポートしてください。これにより、ReflectオブジェクトにメタデータAPIが拡張され、デコレータが型情報を利用できるようになります。

// src/main.ts
import "reflect-metadata"; // 必ずファイルの先頭に記述
// 以降のDIコンテナ実装コード...

2. DIコンテナクラスの作成

依存関係を登録し、解決する中心となるContainerクラスを作成します。

// src/container.ts
import "reflect-metadata"; // コンテナ自身がメタデータを使うため

// サービスを識別するための抽象的なトークン（Symbolや文字列）
type ServiceIdentifier<T> = string | Symbol | NewableFunction | Abstract<T>;

// 具象クラスの型
interface NewableFunction<T = any> {
  new (...args: any[]): T;
}

// 抽象クラスの型
interface Abstract<T> {
  prototype: T;
}

// 依存関係の解決方法を定義するインターフェース
interface Binding<T> {
  concrete: NewableFunction<T>;
  singleton: boolean;
  instance?: T; // シングルトンの場合にインスタンスを保持
}

export class Container {
  private bindings = new Map<ServiceIdentifier<any>, Binding<any>>();

  /**
   * サービスをコンテナに登録する
   * @param identifier サービス識別子（インターフェースやクラス）
   * @param concrete 具象クラス
   * @param singleton trueの場合、シングルトンとして登録
   */
  bind<T>(identifier: ServiceIdentifier<T>): { to: (concrete: NewableFunction<T>) => { inSingletonScope: () => void } } {
    const binding: Binding<T> = {
      concrete: null as any, // 初期化時にnullを設定し、toメソッドで設定
      singleton: false,
    };
    this.bindings.set(identifier, binding);

    return {
      to: (concrete: NewableFunction<T>) => {
        binding.concrete = concrete;
        return {
          inSingletonScope: () => {
            binding.singleton = true;
          },
        };
      },
    };
  }

  /**
   * サービスをコンテナから取得する
   * @param identifier サービス識別子
   * @returns サービスのインスタンス
   */
  get<T>(identifier: ServiceIdentifier<T>): T {
    const binding = this.bindings.get(identifier);

    if (!binding) {
      // 登録されていないクラスの場合は、そのままインスタンス化を試みる
      if (typeof identifier === 'function' && Reflect.hasMetadata('design:paramtypes', identifier)) {
        return this.resolve(identifier as NewableFunction<T>);
      }
      throw new Error(`No matching binding found for service identifier: ${String(identifier)}`);
    }

    if (binding.singleton) {
      if (!binding.instance) {
        binding.instance = this.resolve(binding.concrete);
      }
      return binding.instance;
    }

    return this.resolve(binding.concrete);
  }

  /**
   * 依存関係を解決し、インスタンスを生成する
   * @param constructor 具象クラスのコンストラクタ
   * @returns クラスのインスタンス
   */
  private resolve<T>(constructor: NewableFunction<T>): T {
    // reflect-metadata を使用してコンストラクタの引数の型を取得
    // emitDecoratorMetadata: true が必要
    const paramTypes: any[] = Reflect.getMetadata("design:paramtypes", constructor) || [];

    const dependencies = paramTypes.map((paramType: NewableFunction<any>) => {
      // 依存する型がコンテナに登録されているか確認し、解決
      // 登録されていない場合は、その型自体を識別子として解決を試みる（再帰呼び出し）
      return this.get(paramType);
    });

    return new constructor(...dependencies);
  }
}

export const container = new Container(); // グローバルなコンテナインスタンス

解説:

ServiceIdentifier: サービスの識別子としてSymbolやクラスのコンストラクタ関数を受け取れるようにします。
bind(): 抽象と具象クラスを紐付け、シングルトンかどうかのライフサイクルを設定します。
get(): 指定された識別子に対応するインスタンスを返します。シングルトンの場合は既存のインスタンスを再利用します。
resolve(): ここがDIコンテナの核です。Reflect.getMetadata("design:paramtypes", constructor)を使って、コンストラクタの引数の型情報を実行時に取得します。取得した型情報に基づいて、再帰的にget()を呼び出し、依存関係を解決してインスタンスを生成します。

3. `@injectable` デコレータの作成

サービスとしてコンテナに登録したいクラスにマークするためのデコレータを作成します。このデコレータは特に何も処理しませんが、クラスがDIの対象であることを明示する役割を持ちます。

// src/decorators.ts
import { container } from "./container"; // 自作コンテナをインポート

/**
 * クラスをDIコンテナで管理されるサービスとしてマークするデコレータ
 * TypeScript 5.0以降の標準デコレータAPIを使用
 */
export function Injectable<T extends NewableFunction>(target: T, context: ClassDecoratorContext<T>) {
  // コンテナに自動的にバインドする（識別子としてクラス自体を使用）
  // このデコレータが適用されたクラスは、後で container.get(MyService) で取得できるようになる
  container.bind(target).to(target);
  // 現時点では、クラスの振る舞いを変更する特別な処理は不要だが、将来的に拡張可能
  return target;
}

/**
 * 依存関係を注入するためのデコレータ（今回はコンストラクタインジェクションをresolveで対応するため、明示的なデコレータは不要だが、概念として示す）
 * プロパティインジェクションや、特定の識別子で注入したい場合に利用する
 */
// export function Inject(identifier: ServiceIdentifier<any>) {
//   return function (target: any, context: ClassFieldDecoratorContext | ClassMethodDecoratorContext | ClassGetterDecoratorContext | ClassSetterDecoratorContext) {
//     // ここでプロパティのメタデータなどを記録し、DIコンテナが解決時に利用できるようにする
//     // 今回はコンストラクタインジェクションに限定するため、このデコレータは使用しない
//   };
// }

ポイント:

@Injectableデコレータは、TypeScript 5.0のClass Decorator API (target, context) に準拠しています。
このデコレータが適用されたクラスは、自動的にコンテナにバインドされ、後でcontainer.get(MyService)のようにクラス名で取得できるようになります。

4. サービスと依存関係の定義

実際にDIコンテナで管理するサービスと、その依存関係を定義します。

// src/services.ts
import { Injectable } from "./decorators";
import { container } from "./container";

interface Logger {
  log(message: string): void;
}

@Injectable // このクラスはDIコンテナで管理される
class ConsoleLogger implements Logger {
  log(message: string): void {
    console.log(`[ConsoleLogger] ${message}`);
  }
}

interface Mailer {
  send(to: string, subject: string, body: string): void;
}

@Injectable
class SmtpMailer implements Mailer {
  constructor(private logger: Logger) { // Loggerに依存
    this.logger.log("SmtpMailer initialized.");
  }

  send(to: string, subject: string, body: string): void {
    this.logger.log(`Sending email to ${to}: ${subject} - ${body}`);
  }
}

@Injectable
class UserService {
  constructor(private logger: Logger, private mailer: Mailer) { // LoggerとMailerに依存
    this.logger.log("UserService initialized.");
  }

  createUser(name: string, email: string): void {
    this.logger.log(`Creating user: ${name} (${email})`);
    this.mailer.send(email, "Welcome!", `Hello ${name}, welcome to our service!`);
  }
}

// 抽象と具象のバインディング
// インターフェースを使う場合はSymbolなどで識別子を定義し、bindする
// 今回はクラスを識別子として直接bindする例
container.bind(Logger).to(ConsoleLogger).inSingletonScope(); // LoggerはConsoleLoggerとしてシングルトン
container.bind(Mailer).to(SmtpMailer); // MailerはSmtpMailerとして（デフォルトはトランジェント）
// UserServiceは@Injectableで自動バインドされるが、明示的にバインドしても良い
// container.bind(UserService).to(UserService);

ポイント:

@Injectableデコレータをクラスに適用することで、そのクラスがDIコンテナの管理対象であることを示します。
コンストラクタインジェクションにより、UserServiceはLoggerとMailerに依存していることを明示しています。DIコンテナがこれらの依存関係を自動的に解決します。
container.bind(Logger).to(ConsoleLogger).inSingletonScope(); のように、インターフェース（ここではLoggerクラス自体をインターフェースの代わりとして使用）と具象クラスを紐付け、ライフサイクル（シングルトン）を設定できます。

5. アプリケーションのエントリポイント

作成したDIコンテナとサービスを使ってアプリケーションを起動します。

// src/main.ts
import "reflect-metadata"; // 必ずファイルの先頭に記述
import { container } from "./container";
import { UserService } from "./services"; // これをインポートすると@Injectableが実行され、コンテナに登録される

// UserServiceのインスタンスをコンテナから取得
// 依存するLoggerとMailerは自動的に解決され、注入される
const userService = container.get(UserService);

userService.createUser("Alice", "alice@example.com");

// 別のUserServiceインスタンスを取得してみる (シングルトンではないので新しいインスタンス)
const anotherUserService = container.get(UserService);
console.log(userService === anotherUserService); // false (デフォルトはトランジェント)

// シングルトンとして登録したLoggerを取得してみる
const logger1 = container.get(ConsoleLogger);
const logger2 = container.get(ConsoleLogger);
console.log(logger1 === logger2); // true (ConsoleLoggerはシングルトンとして登録されているため)

このコードを実行すると、UserServiceが依存するConsoleLoggerとSmtpMailerが自動的に解決され、適切なインスタンスが注入されることが確認できます。

npx tsc # コンパイル
node dist/main.js # 実行

出力例:

[ConsoleLogger] SmtpMailer initialized.
[ConsoleLogger] UserService initialized.
[ConsoleLogger] Creating user: Alice (alice@example.com)
[ConsoleLogger] Sending email to alice@example.com: Welcome! - Hello Alice, welcome to our service!
false
true

既存のDIコンテナライブラリの活用例

自作DIコンテナの原理を理解した上で、実プロジェクトではInversifyJSやTypeDIといった高機能なライブラリを利用するのが一般的です。ここでは、それぞれの基本的な使い方と特徴を簡単に紹介します。

InversifyJS を使ったDIコンテナ

InversifyJSは、Symbolを識別子として使用し、強力な型チェックと柔軟なバインディング機能を提供するIoCコンテナです。注意点として、InversifyJSは現時点（2024年7月）でレガシーな--experimentalDecorators形式のデコレータに依存しています。

// tsconfig.json にて "experimentalDecorators": true, "emitDecoratorMetadata": true が必須

// src/types.ts (識別子を定義するファイル)
export const TYPES = {
  Warrior: Symbol.for("Warrior"),
  Weapon: Symbol.for("Weapon"),
  Katana: Symbol.for("Katana"),
  Shuriken: Symbol.for("Shuriken"),
};

// src/interfaces.ts
export interface Weapon {
  hit(): string;
}
export interface Warrior {
  fight(): string;
  sneak(): string;
}

// src/entities.ts
import { injectable, inject } from "inversify";
import { TYPES } from "./types";
import { Weapon, Warrior } from "./interfaces";

@injectable()
export class Katana implements Weapon {
  hit() { return "cut!"; }
}

@injectable()
export class Shuriken implements Weapon {
  hit() { return "throw!"; }
}

@injectable()
export class Ninja implements Warrior {
  public constructor(
    @inject(TYPES.Katana) private _katana: Weapon,
    @inject(TYPES.Shuriken) private _shuriken: Weapon
  ) {}

  public fight() { return this._katana.hit(); }
  public sneak() { return this._shuriken.hit(); }
}

// src/inversify.config.ts (DIコンテナの設定)
import { Container } from "inversify";
import { TYPES } from "./types";
import { Warrior, Weapon } from "./interfaces";
import { Ninja, Katana, Shuriken } from "./entities";

const myContainer = new Container();
myContainer.bind<Warrior>(TYPES.Warrior).to(Ninja);
myContainer.bind<Weapon>(TYPES.Katana).to(Katana);
myContainer.bind<Weapon>(TYPES.Shuriken).to(Shuriken);

export { myContainer };

// src/main.ts
import "reflect-metadata"; // 最初にインポート
import { myContainer } from "./inversify.config";
import { TYPES } from "./types";
import { Warrior } from "./interfaces";

const ninja = myContainer.get<Warrior>(TYPES.Warrior);
console.log(ninja.fight()); // "cut!"
console.log(ninja.sneak()); // "throw!"

TypeDI を使ったDIコンテナ

TypeDIは、シンプルさを追求したDIコンテナで、TypeScriptの型情報とreflect-metadataを組み合わせて使用します。TypeScript 5.0以降の標準デコレータと互換性があります。

// tsconfig.json にて "experimentalDecorators": false, "emitDecoratorMetadata": true が必須

// src/main.ts
import "reflect-metadata"; // 最初にインポート
import { Service, Inject, Container } from "typedi";

interface Logger {
  log(message: string): void;
}

@Service() // このクラスをサービスとして登録
class ConsoleLogger implements Logger {
  log(message: string): void {
    console.log(`[ConsoleLogger] ${message}`);
  }
}

@Service()
class UserService {
  // @Inject(() => ConsoleLogger) は、TypeScriptの型情報を実行時に利用するためのTypeDIの記法
  // コンストラクタ引数の型がインターフェースの場合や、特定の識別子で注入したい場合に利用
  constructor(@Inject(() => ConsoleLogger) private logger: Logger) {}

  createUser(name: string): void {
    this.logger.log(`User ${name} created.`);
  }
}

const userService = Container.get(UserService); // コンテナからUserServiceのインスタンスを取得
userService.createUser("Alice"); // "[ConsoleLogger] User Alice created."

よくあるエラーとハマりどころ

DIコンテナとデコレータを使う上で、多くのエンジニアが遭遇するエラーとその解決策をまとめました。

1. `reflect-metadata` のインポート忘れ、または順序の問題

エラー: TypeError: Reflect.metadata is not a function や、デコレータが正しく機能しない。
原因: reflect-metadataは、デコレータが使用される前に一度だけインポートされている必要があります。
回避策: アプリケーションのエントリポイント（例: src/main.ts）の先頭に import "reflect-metadata"; を記述します。

2. `tsconfig.json` の設定不足 (`experimentalDecorators`, `emitDecoratorMetadata`)

エラー: デコレータがコンパイルエラーになる、または実行時にメタデータが取得できない。
原因: tsconfig.jsonのcompilerOptionsで、デコレータとメタデータ出力に関する設定が不足しているか、誤っている。
回避策:
- InversifyJSのようなレガシーデコレータに依存するライブラリの場合: "experimentalDecorators": true, "emitDecoratorMetadata": trueを設定。
- TypeScript 5.0以降の標準デコレータを使用し、かつreflect-metadataを利用する場合（TypeDI、自作DIコンテナ）: "experimentalDecorators": false（または削除）, "emitDecoratorMetadata": trueを設定。
- target, module, moduleResolutionも適切に設定されていることを確認してください。

3. DIコンテナへのバインディング忘れ、または誤った識別子の使用

エラー: 依存関係を解決しようとしたときに、No matching bindings found for serviceIdentifierのようなエラーが発生する。
原因: DIコンテナが、どの抽象にどの具象クラスを紐づけるかを知らない、または@injectで指定した識別子とコンテナに登録した識別子が一致していない。
回避策:
- すべての依存関係がDIコンテナに正しくバインドされているか確認する。
- @injectデコレータやcontainer.get()で使用する識別子（Symbolやクラス名）が、container.bind()で登録されている識別子と完全に一致していることを確認する。特にSymbol.for()を使用する場合は、同じ文字列を渡すように注意する。

設計上のトレードオフとベストプラクティス

DIコンテナとTypeScript Decoratorは強力なツールですが、その導入にはトレードオフが存在し、効果的に活用するためにはいくつかのベストプラクティスがあります。

トレードオフ

学習コストと複雑性: デコレータの動作原理、DIコンテナのライフサイクル管理、設定などを理解するための初期学習コストは存在します。
ランタイムオーバーヘッド: メタデータの読み取りや依存関係の解決には、わずかながらランタイムオーバーヘッドが発生する可能性があります。ほとんどのアプリケーションでは問題になりませんが、パフォーマンスが極めて重要な場面では考慮が必要です。
マジックの増加: デコレータはコードの振る舞いを宣言的に変更するため、一見して何が起こっているのか分かりにくい「マジック」が増える可能性があります。デバッグが難しくなる場合もあります。

ベストプラクティス

インターフェース（抽象）への依存: 具象クラスではなく、インターフェースや抽象クラスに依存するように設計することで、疎結合性を高め、テスト容易性や保守性を向上させます。
コンストラクタインジェクションの活用: 依存関係はコンストラクタを通じて注入するのが最も推奨される方法です。これにより、クラスが必要とする依存関係が明確になり、テスト時にモックオブジェクトを簡単に注入できます。
識別子の統一と管理: 依存関係の識別子にはSymbolを使用し、一箇所で集中管理するファイル（例: types.ts）を作成することが推奨されます。これにより、typoによるエラーを防ぎ、コードの可読性を向上させます。
DIコンテナの適切なスコープ管理: シングルトン（アプリケーション全体で1つのインスタンス）やトランジェント（要求ごとに新しいインスタンス）など、依存オブジェクトのライフサイクルを適切に管理することで、リソースの効率的な利用と予期せぬ副作用の回避が可能です。
テスト容易性の確保: DIコンテナを使用することで、ユニットテスト時に依存オブジェクトをモックやスタブに簡単に差し替えることができます。このメリットを最大限に活かす設計を心がけましょう。

まとめ

この記事では、TypeScript 5.0以降の標準Decoratorとreflect-metadataを活用し、DIコンテナをゼロから自作する手順を解説しました。

TypeScriptのデコレータが、クラスのメタデータ付与や振る舞い変更に利用できること。
reflect-metadataとtsconfig.jsonのemitDecoratorMetadata設定が、実行時型情報取得に不可欠であること。
DIコンテナが依存関係の解決とインスタンス生成を自動化し、疎結合でテスト容易なコードを実現すること。
InversifyJSやTypeDIといった既存ライブラリの利用法と、その選定基準。
よくあるエラーとその解決策、そして設計上のベストプラクティス。

これらの知識は、大規模なTypeScriptアプリケーション開発において、保守性、拡張性、テスト容易性を飛躍的に向上させるための基盤となります。ぜひ、ご自身のプロジェクトでDIコンテナの導入を検討してみてください。さらに深く学びたい方は、各DIコンテナライブラリの公式ドキュメントや、TC39 Decorators Proposalの詳細を参照することをお勧めします。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

TypeScript Decoratorで学ぶ！ゼロから作る依存性注入コンテナ

TypeScript DecoratorとDIコンテナの基本を理解する

TypeScript Decoratorとは何か？

依存性注入（DI）コンテナとは何か？

環境セットアップとtsconfig.jsonの重要設定

プロジェクトの初期設定

tsconfig.jsonの重要設定

ゼロからTypeScript DIコンテナを自作する

1. reflect-metadataのインポート

2. DIコンテナクラスの作成

3. @injectable デコレータの作成

4. サービスと依存関係の定義

5. アプリケーションのエントリポイント

既存のDIコンテナライブラリの活用例

InversifyJS を使ったDIコンテナ

TypeDI を使ったDIコンテナ

よくあるエラーとハマりどころ

1. reflect-metadata のインポート忘れ、または順序の問題

2. tsconfig.json の設定不足 (experimentalDecorators, emitDecoratorMetadata)

3. DIコンテナへのバインディング忘れ、または誤った識別子の使用

設計上のトレードオフとベストプラクティス

トレードオフ

ベストプラクティス

まとめ

1. `reflect-metadata`のインポート

3. `@injectable` デコレータの作成

1. `reflect-metadata` のインポート忘れ、または順序の問題

2. `tsconfig.json` の設定不足 (`experimentalDecorators`, `emitDecoratorMetadata`)