ヘキサゴナルアーキテクチャ - ポートとアダプターで外部依存を分離する

ヘキサゴナルアーキテクチャとは、アプリケーション本体を外部のUI、DB、APIから分離し、ポートとアダプターを通じて接続する設計思想です。

一言でいうと

アプリケーションの中心を「外から呼ばれる口」と「外へ出ていく口」で囲む設計です。

「Webから呼ばれる」「CLIから呼ばれる」「DBに保存する」「外部APIへ問い合わせる」といった詳細を、アプリケーション本体から切り離します。

登場人物

ポートは「約束」、アダプターは「接続部品」です。

処理の流れ

注文作成APIを例にします。

中心のユースケースは、HTTPで呼ばれたのか、CLIで呼ばれたのかを知りません。DBがPostgreSQLなのか、MongoDBなのかも知りません。

入力ポートと出力ポート

入力ポートは「このアプリで何ができるか」を表します。

interface CreateOrderUseCase {
 execute(input: CreateOrderInput): Promise<CreateOrderOutput>;
}

出力ポートは「外部へ何を依頼したいか」を表します。

interface OrderRepository {
 save(order: Order): Promise<void>;
 findById(id: string): Promise<Order | null>;
}

この2つを分けることで、アプリケーションの中心は外部技術に依存しにくくなります。

クリーンアーキテクチャとの違い

両者は対立するものではありません。どちらも、ビジネスロジックを外部詳細から守るための考え方です。

よくある誤解

すべてにinterfaceが必要

1つしか実装がなく、差し替える予定もないものまで無理に抽象化すると読みにくくなります。外部I/Oやテストで差し替えたい部分から始めるのが現実的です。

Controllerがユースケースの代わりになる

Controllerは入力アダプターです。業務ルールをControllerに書き始めると、HTTP以外から再利用しにくくなります。

DBアダプターに業務ルールを書いてよい

DBアダプターの責務は保存と取得です。割引計算、状態遷移、権限判断などはコア側に置きます。

導入チェックリスト

• ユースケースがHTTPやDBの型を直接受け取っていないか
• 外部API呼び出しを出力ポートとして抽象化できているか
• Controllerに業務判断を書きすぎていないか
• DBなしでユースケースのテストを書けるか
• CLIやバッチから同じユースケースを呼べるか

まとめ

ヘキサゴナルアーキテクチャは、アプリケーションを外部技術から守るための境界設計です。

ポートはアプリの約束、アダプターは外部との接続部品です。この区別ができると、UI、DB、外部APIを変えても中心のユースケースを保ちやすくなります。

参考リソース

• Alistair Cockburn: Hexagonal Architecture
• Martin Fowler: Inversion of Control Containers and the Dependency Injection pattern
• Microsoft: Architecture principles

関連記事

• クリーンアーキテクチャ
• 依存性注入（DI）入門
• REST API設計原則

×

PR

×

PR