なぜ必要なのか

機能同士の干渉は増えたが、別サービスにすると運用負担が大きい。一つの配布単位の中で境界を作りたい場面です。

どう解決するのか

  1. 架空の読書アプリ。一チーム、アプリv1にカタログ・ライブラリ・課金を含む。A17はタグなし。
  2. ライブラリ所有のテーブルにタグ保存を追加し、アプリv2をデプロイ。課金の動作は同じ。一つのDBでもテーブルはモジュール別に所有し、他モジュールの直接アクセスは禁止。
  3. ライブラリがカタログAPIをプロセス内で呼び、travelを記録。参照失敗ならタグなしのまま。復旧後に再試行。
内部の契約、共通のリリース

説明用の架空の例

内部の契約、共通のリリース

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

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

デプロイ単位 · 1

アプリv1 → アプリv2

  1. カタログ

    API記事の参照
    所有する内部実装カタログ所有のテーブル

  2. ライブラリ

    タグ機能を追加
    APIA17のタグを設定：travel
    所有する内部実装ライブラリ所有のテーブル＋タグ項目

  3. 課金

    API動作は同じ
    所有する内部実装課金所有のテーブル

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

他モジュールのテーブルに直接アクセスしない。呼び出しはそのAPIを通す。

一つの共有データベース、テーブルの所有権は分離。ライブラリの保存変更も共通リリースに含む。

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

モノリスの一種：リリースとプロセス障害を共有。API境界はコード規則とテストで守り、フォルダーだけに頼りません。

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

どんな考え方なのか

モジュラーモノリスは一つのデプロイ内に明示的な境界を設けます。モジュールAPIが所有する内部実装を保護します。引き続きモノリスです。Fowler

フォルダー分け以上の境界強制が必要で、リリース・プロセス障害は共有します。内部にヘキサゴナルのポートを置けます。