なぜ必要なのか

登山者がガイドを保存し、追加機能を買うアプリを作るとします。週末タグの追加が課金コードに波及しそうです。チームは別サービスを運用せず、一括更新内で所有範囲を明確にしたいのです。

どう解決するのか

  1. 一チームがカタログ・ライブラリ・課金を一括更新。保存した登山ガイドはタグなし。
  2. ライブラリの所有テーブルにタグ保存を追加し、アプリv2を配布。課金の動作は同じ。一つのDBでもテーブルはモジュール別に所有し、他モジュールの直接アクセスは禁止。
  3. ライブラリがカタログAPIをプロセス内で呼び、週末を記録。参照失敗はタグなし。復旧後に再試行。
内部の契約、共通のリリース

説明用の架空の例

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

登山アプリ · 一チーム · 登山ガイドに週末タグなし

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

デプロイ単位 · 1

アプリv1 → アプリv2

  1. カタログ

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

  2. ライブラリ

    タグ機能を追加
    API登山ガイドのタグを設定：週末
    所有する内部実装ライブラリ所有のテーブル＋タグ項目

  3. 課金

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

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

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

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

  1. 参照成功 → 週末を記録 → 登山ガイドのタグは週末。
  2. 書き込み前に参照失敗 → タグなし。失敗を伝え、復旧後に再試行。

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

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

モジュールAPIはソースとデータ所有を守ります。配布とプロセス障害の境界は共有したままです。

どんな考え方なのか

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

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