なぜ必要なのか

読者がWebかCLIから貸出規則を保存する図書館ガイドを作るとします。画面に検証と保存を置くと規則が重複します。制作側は一つのプロセス内で表示・処理・保存の流れを分けたいと考えます。

どう解決するのか

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

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

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

説明用の架空の例

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

ジュンが貸出ルールのページを保存したい · 最初は未保存

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

  1. 表示

    HTTP / CLI

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

    ソースの依存 ↓

    実行時の呼び出し ↓

  2. アプリケーション

    SaveArticle(ジュン, 貸出ルール)

    IDの検証と保存の調整

    ソースの依存 ↓

    実行時の呼び出し ↓

  3. 保存

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

    保存項目を1件記録

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

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

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

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

論理層は一つのプロセスと配布を共有します。プロセス障害は全層に及ぶ場合があり、矢印は通信接続ではありません。

どんな考え方なのか

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

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

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