なぜ必要なのか

画面変更、業務ルール、保存処理が絡まっています。何をどこで直すか分かるよう、役割を分ける必要があります。

どう解決するのか

  1. 単一プロセスでR1のA17は未保存。メモリまたは組み込みDBを使う。
  2. HTTP・CLIの表示層がアプリ層の検証を参照・呼び出し、そこから保存層を参照・呼び出す。この閉鎖型の例では飛び越しは禁止。
  3. 成功は0 → 1件、反復も1件。空ID・書き込み前の失敗は0件。修正後に再試行。

HTTPをCLIへ替えても検証の位置は同じ。

論理レイヤーは一つの配置に共存できます

説明用の架空の例

三つの責務、一つのプロセス

R1 · A17 · 最初は未保存

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

  1. 表示

    HTTP / CLI

    IDを受け取り、保存完了を表示

    ソースの依存 ↓

    実行時の呼び出し ↓

  2. アプリケーション

    SaveArticle(R1, A17)

    IDの検証と保存の調整

    ソースの依存 ↓

    実行時の呼び出し ↓

  3. 保存

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

    保存項目を1件記録

↑ 保存完了の戻り：保存 → アプリケーション → 表示

閉鎖型の例：飛び越し禁止。HTTPをCLIに替えても検証はアプリケーションに残る。

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

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

どんな考え方なのか

レイヤードアーキテクチャは責務を分け、レイヤー間の依存を制限します。論理レイヤーごとに別のマシンが必要なわけではありません。Microsoft

ポートで保存への依存を逆転できます。フォルダー名だけではルールを強制できません。

中継だけの層にも管理費用がかかります。