エンタープライズ企業のアーキテクチャ設計をコンサルティングする際、最初に必ず聞かれる質問があります：「最初からマイクロサービスで開発すべきでしょうか？」私たちの短い答えは「いいえ」です。長い答えがこの記事です。
早期マイクロサービスの隠れたコスト
2024年のHRM開発プロジェクトにおいて、当初開発チームは12の境界づけられたコンテキストを12の個別サービスに分割することを希望していました。私たちはそれを1つのモジュラーモノリスに統合するよう提案しました。その決定により、約4ヶ月のインフラ構築期間と2名のフルタイムDevOpsエンジニアの工数を削減でき、チームは開発初期の半年間をサービスメッシュのデバッグではなく給料計算ロジックに集中させることができました。
切り離すべきタイミングとは？
モジュールを独立サービスへ分離するためには、以下の3つの条件を定義しています：(1) トラフィック規模の著しい差異（通知モジュールが他機能の100倍のアクセスを受ける等）、(2) 独立デプロイの必要性（モジュール担当チームが8〜10名を超えた場合）、(3) セキュリティ・コンプライアンス要件の分離（決済モジュールのPCI-DSSスコープ限定等）。
実践パターン：明確な境界、単一デプロイ
実際のコードでは、ArchUnit（Java）やConventional Commits ＋ カスタムリンター（.NET, Node）を用いてモジュール境界を強制しています。各モジュールは専用フォルダを持ち、他モジュールのクラスを直接インポートすることは禁止されています。DBスキーマもPostgreSQL内で分割されています。サービス分離が必要になった際も、内部インターフェースをHTTPクライアントに置き換えるだけで済みます。
現実的な結論
モジュラーモノリスは「変装したモノリス」ではありません — マイクロサービスと比較して運用コストが圧倒的に低い、洗練されたアーキテクチャ上の選択です。まずはここから始めましょう。18ヶ月経過しても分割の必要性が生じなければ、今後もおそらく必要ありません。
