なぜ必要なのか

小さなアプリを扱いやすい手順で公開したい。複数サービスの個別配布や調整が、今の課題より大きくなることがあります。

どう解決するのか

  1. 架空の読書アプリ。一チーム、アプリv1にカタログ・ライブラリ・課金を含む。A17はタグなし。
  2. ライブラリにタグ機能を加え、アプリv2をデプロイ。課金の動作は同じでも同じ成果物に含まれる。共有データベースはアプリが所有。
  3. ライブラリがプロセス内でカタログを参照し、travelを記録。書き込み前の参照失敗ならタグなしのまま。復旧後に再試行。
複数の機能を含む一つのデプロイ単位

説明用の架空の例

一つの成果物をまとめて更新

読書アプリ · 一チーム · A17はタグなし

変更：ライブラリにタグを追加。課金の動作は同じ。

デプロイ単位 · 1

アプリv1 → アプリv2

サーバーアプリケーション全体をビルド・デプロイ

  1. カタログ

    動作は同じ

  2. ライブラリ

    タグ機能を追加

  3. 課金

    動作は同じ

ライブラリ → カタログ · プロセス内呼び出し

機能の枠は内部のモジュール構成を規定しません。

共有データベース · 所有者：アプリ

カタログ / ライブラリ / 課金

カタログ参照の成功後、ライブラリがタグを記録。

  1. 参照成功 → travelを記録 → A17のタグはtravel。
  2. 書き込み前に参照失敗 → タグなし。失敗を伝え、復旧後に再試行。

レプリカは同じ成果物のコピーで、別サービスではありません。プロセス停止はそのレプリカの全機能に影響し得ます。

所有権の枠はアクセス規則を示し、データベースのマシン数を示しません。

どんな考え方なのか

モノリスはサーバーアプリケーションを一単位でデプロイします。同じ成果物のレプリカを増やしてもモノリスであり、内部にモジュールを置けます。Lewis・Fowler

リリースとプロセス障害は共有します。境界が重要になれば明示的なモジュールを加えます。