モノリスファースト
新規プロジェクトではまずモノリスで構築し、ドメイン理解が深まってからマイクロサービスに分割する戦略
アーキテクチャ設計
モノリスファーストとは
モノリスファースト (Monolith First) は、Martin Fowler が提唱したアプローチで、新規プロジェクトではまずモノリスで構築し、ドメインの理解が深まった段階でマイクロサービスに分割する戦略である。
なぜモノリスから始めるか
初期段階ではドメイン境界が不明確で、正しいサービス分割が分からない。分散システムはネットワーク、整合性、デプロイの複雑さを伴い、1〜5 人の小さなチームには過剰だ。モノリスの方が初期開発が速く、ドメインの理解が深まってから分割する方が、正しい境界でサービスを切り出せる。
モノリス → マイクロサービスの段階
モノリス → マイクロサービスの段階を図で示す。
Phase 1: モノリス
1 つの Lambda に全機能
Phase 2: モジュラーモノリス
モジュール境界を明確化、内部 API で分離
Phase 3: マイクロサービス
モジュールを独立したサービスに分割
いつ分割するか
いつ分割するかの判断基準を以下にまとめる。
| シグナル | 説明 |
|---|---|
| デプロイが遅い | 小さな変更でも全体をデプロイ |
| チームが 2 つ以上 | チーム間の調整コストが増加 |
| スケーリング要件が異なる | 注文処理と検索で負荷が違う |
| ドメイン境界が明確になった | 注文、ユーザー、決済が独立 |
より深く学ぶには関連書籍が役立つ。
この記事は役に立ちましたか?
関連用語
モジュラーモノリス
モノリスの内部をモジュールに分割し、マイクロサービスの利点を取り入れたアーキテクチャ
マイクロサービス
1 つの大きなアプリケーションを複数の小さなサービスに分割し、それぞれが独立してデプロイ・スケール可能な状態で協調動作するアーキテクチャパターン
モノリス
全機能を 1 つのデプロイ単位にまとめたアーキテクチャで、シンプルだが大規模化で課題が生じる
Strangler Fig パターン
レガシーシステムを段階的に新システムへ移行する設計パターン
認知負荷
開発者がコードを理解・変更するために必要な精神的な労力の量
マイクロフロントエンド
フロントエンドをチームごとに独立した小さなアプリケーションに分割し、個別にデプロイ可能にするアーキテクチャ