なぜ必要なのか

近所の人が料理本を探して保存し、追加機能を購入するレシピアプリを作るとします。少人数の一チームが保存した本に家族タグを加えたいものの、別々のリリース調整は負担です。機能別の日程より一括更新を優先します。

どう解決するのか

  1. 一チームがカタログ・ライブラリ・課金を一括更新します。保存した地域の料理本にはタグがありません。
  2. ライブラリにタグ機能を加え、アプリv2をデプロイ。課金の動作は同じでも同じ成果物に含まれる。共有データベースはアプリが所有。
  3. ライブラリがプロセス内でカタログを参照し、家族を記録。書き込み前の参照失敗ならタグなしのまま。復旧後に再試行。
複数の機能を含む一つのデプロイ単位

説明用の架空の例

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

レシピアプリ · 一チーム · 地域の料理本に家族タグなし

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

デプロイ単位 · 1

アプリv1 → アプリv2

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

  1. カタログ

    動作は同じ

  2. ライブラリ

    タグ機能を追加

  3. 課金

    動作は同じ

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

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

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

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

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

  1. 参照成功 → 家族を記録 → 地域の料理本のタグは家族。
  2. 書き込み前に参照失敗 → タグなし。失敗を伝え、復旧後に再試行。

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

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

一つの配布に複数の複製を置けます。プロセス障害はその中の機能に及び、コードを戻してもDBの書き込みは戻りません。

どんな考え方なのか

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

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