モノリスファースト

モノリスファーストとは

モノリスファースト (Monolith First) は、Martin Fowler が提唱したアプローチで、新規プロジェクトではまずモノリスで構築し、ドメインの理解が深まった段階でマイクロサービスに分割する戦略である。

なぜモノリスから始めるか

初期段階ではドメイン境界が不明確で、正しいサービス分割が分からない。分散システムはネットワーク、整合性、デプロイの複雑さを伴い、1〜5 人の小さなチームには過剰だ。モノリスの方が初期開発が速く、ドメインの理解が深まってから分割する方が、正しい境界でサービスを切り出せる。

モノリス → マイクロサービスの段階

モノリス → マイクロサービスの段階を図で示す。

Phase 1: モノリス
  1 つの Lambda に全機能

Phase 2: モジュラーモノリス
  モジュール境界を明確化、内部 API で分離

Phase 3: マイクロサービス
  モジュールを独立したサービスに分割

いつ分割するか

いつ分割するかの判断基準を以下にまとめる。

シグナル	説明
デプロイが遅い	小さな変更でも全体をデプロイ
チームが 2 つ以上	チーム間の調整コストが増加
スケーリング要件が異なる	注文処理と検索で負荷が違う
ドメイン境界が明確になった	注文、ユーザー、決済が独立

分割は「全部を一度に」ではなく、境界が固まった部分から 1 つずつ切り出すのが定石だ。既存モノリスの周囲に新サービスを少しずつ生やして置き換えていく方法はストラングラーフィグパターンと呼ばれ、モノリスファーストの出口戦略としてよく組み合わされる。

反対意見も知っておく

モノリスファーストには「最初から境界を意識しないと、モノリス内部が密結合になり、後から切り出せなくなる」という反論もある。実際、分割を想定せずに書かれたモノリスは、データベースのテーブルをモジュール間で共有してしまい、切り出しの難易度が跳ね上がることが多い。この対立を実務に落とすと、「デプロイ単位はモノリスで始めつつ、モジュール境界とデータの所有権だけは最初から分けておく」というモジュラーモノリス寄りの折衷が現実解になる。マイクロサービスは目的ではなく、組織とドメインの複雑さに応じて支払うコストであるという視点を忘れないことが、この戦略の本質だ。

より深く学ぶには関連書籍が役立つ。