📰
BackendTutorialEN → JA
40

zenn ·

Goでクリーンアーキテクチャを導入するとinterfaceが爆発する問題への処方箋

要約

Goでクリーンアーキテクチャを導入する際、`usecase`層が依存する外部サービス(リポジトリ、ロガー、メトリクスなど)のインターフェースをどこに定義するかという問題が挙げられます。従来の考え方では`usecase`層で定義し、`driver`層で実装しますが、これにより`driver`層にテストのためのモック用インターフェースが大量に生成され、「インターフェース爆発」を引き起こします。本記事では、Goの暗黙的なインターフェース実装の特性を活かし、このような外部依存サービスのインターフェースは`driver`層に定義することで、`usecase`層を簡潔に保ち、インターフェースの肥大化を防ぐ処方箋を提示しています。これにより、`usecase`層は抽象に依存しつつも、`driver`層が自身の依存する外部システムとの契約を定義する形となります。

📌

Key Points

  • •Goでクリーンアーキテクチャを採用すると、特に外部サービス(リポジトリ、ロガー等)のモック化のために`driver`層にテスト用のインターフェースが大量に定義され、「インターフェース爆発」が発生する問題がある。
  • •外部依存サービスのインターフェースは`usecase`層でなく、そのサービスを実装する`driver`層で定義することを推奨。これにより、インターフェースが実装と密接になり、テスト時にも`usecase`は抽象に依存したままとなる。
  • •Goの暗黙的インターフェース実装の特性を活かし、抽象を定義する側(ここでは`driver`層)が自身の外部システムへの契約を定義することで、依存性逆転の原則を維持しつつ`usecase`層のインターフェース肥大化を防ぐ。

Why it matters

この処方箋は、Goでのクリーンアーキテクチャ導入時のインターフェース設計の複雑さを軽減し、保守性とテスト容易性を高めるための実践的な指針となるため重要です。

関連エンティティ
GoクリーンアーキテクチャPorts and AdaptersZenn