なぜ必要なのか

業務ルールのテストに実際のデータベースやサーバーが必要だと負担が増えます。外部ツールを交換できる接続点が必要です。

どう解決するのか

  1. 単一プロセスでR1のA17は未保存。HTTP・CLIアダプターが入力ポートからSaveArticleを呼ぶ。
  2. IDを検証し、SaveRepository経由でメモリ・組み込みDBへ保存。保存アダプターはアプリ所有のポートに依存し、アプリは保存実装を直接参照しない。
  3. 成功は0 → 1件、反復も1件。空ID・書き込み前の失敗は0件。修正後に再試行。
接点の技術を替えてもアプリケーションの動作は保つ

説明用の架空の例

接点を替え、アプリケーションを保つ

R1 · A17 · 最初は未保存

単一プロセス · 点線の囲み

1 · 駆動するアダプター

  • HTTP
  • CLI

参照 → 入力ポート

2 · アプリケーション

入力ポートSaveArticle

IDの検証と保存の調整

出力ポート · ここが所有SaveRepository

3 · 駆動されるアダプター

  • メモリ
  • 組み込みデータベース

SaveRepository ← アダプターの参照

実行時の呼び出し

  1. HTTP / CLI
  2. SaveArticle
  3. SaveRepository
  4. メモリ / 組み込みデータベース

破線の経路：出力ポート経由で保存先を呼び、保存完了を呼び出し元に返す。

アプリケーションはアダプター実装を直接参照しません。テストではメモリがデータベースを代替できます。六つの構成要素は必須ではありません。

  • 保存 → 繰り返し：0 → 1 → 1件。保存完了を返す。
  • 空の保存先から：空のIDや書き込み前の失敗 → 0件。修正後に再試行。

HTTP・CLIとメモリ・組み込みデータベースは代替案です。データ移行を意味しません。

どんな考え方なのか

ヘキサゴナルアーキテクチャはポートと技術別アダプターでアプリケーションを接続します。六角形は六つの構成要素を要求しません。Cockburn

内部の方針にはクリーンアーキテクチャの依存ルールを適用できます。

ポートとアダプターで間接処理が増えます。