DI のメリット

DI の価値は「業務変更に追従しやすいこと」です。受注と商品を扱うシステムでは、販売ルール変更や連携先変更が頻繁に起きるため効果が出やすくなります。

メリット1: 実装の差し替えが容易

受注処理が ProductGateway に依存する形にしておけば、 本番は DB 参照、将来は外部商品API、テストではモックという切り替えが容易です。

メリット2: テストが速く安定する

受注ロジックのテスト時に、商品取得と通知送信をモック化しやすくなります。 その結果、テストが速く安定します。 CI でのテスト時間短縮にも直結します。

メリット3: 責務が分離される

クラスの責務を「自分の仕事」に集中できるようになります。 オブジェクト生成の責務はコンテナやファクトリに寄せるため、コードが読みやすくなります。

メリット4: チーム開発で衝突が減る

「受注ロジック担当」「商品連携担当」「通知担当」のように分業しやすくなります。 実装切替ポイントが明確なので、衝突が減ります。

DIとinterfaceの違い

混同されやすいですが、役割が違います。 interface は「型の約束」、DI は「その部品を外から渡す方法」です。

受注の例で見ると、次のような違いです。

// interface だけ導入（まだ DI していない）
class OrderService {
  private final ProductGateway gateway = new ProductDbGateway(); // 実装が固定
}

// interface + DI
class OrderService {
  private final ProductGateway gateway;
  OrderService(ProductGateway gateway) { // 外から受け取る
    this.gateway = gateway;
  }
}

つまり、interface だけでは「受注処理の中で実装固定」のままになりがちです。 DI まで行って初めて、商品取得先を本番DB・外部API・テストモックへ柔軟に切り替えられます。