なぜ必要なのか

業務ルールは画面やデータベースが変わっても保ちたい。詳細技術への直接依存があると、交換がルール変更へ波及します。

どう解決するのか

  1. 単一プロセスでR1のA17は未保存。HTTP・CLIからSaveArticleへIDを渡し、SavedArticleで検証。
  2. SaveRepository経由でメモリ・組み込みDBへ保存。依存はアダプター → ユースケース契約 → ドメイン。呼び出しは外へも進むが、境界は単純なデータだけ。ORM行は外に置く。
  3. 成功は0 → 1件、反復も1件。空ID・書き込み前の失敗は0件。修正後に再試行。
依存の向きと呼び出しの向きは別です

説明用の架空の例

依存は方針へ向かう

R1 · A17 · 最初は未保存

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

1 · フレームワーク・ドライバー

HTTP / CLI · メモリ / 組み込みデータベース

↓ ソースの依存

2 · アダプター

コントローラーはIDを変換、保存アダプターはレコードを変換

↓ ソースの依存

3 · アプリケーションの方針

SaveArticle

SaveRepositoryインターフェースを所有

↓ ソースの依存

4 · ドメインの方針

SavedArticle

空の読者・記事IDを拒否

保存の境界で

← ソースの依存SaveRepository（内側）← 保存アダプター

実行時の呼び出し →SaveArticle → SaveRepository経由 → 保存アダプター（外側）

境界には単純なIDと保存完了の結果のみを渡す。ORM行は外に残す。四つの領域は例であり、必須のフォルダー構成ではありません。

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

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

どんな考え方なのか

クリーンアーキテクチャはソースの依存を方針へ向けます。実行時の呼び出しは内側が所有するインターフェース経由で外へ進めます。Martin

ヘキサゴナルのポートと組み合わせられます。四つのフォルダーは必須ではありません。

境界のデータ変換にも管理費用がかかります。