モジュラーモノリス【modular monolith】
概要

従来の「モノリシック」設計では、すべての機能が一つのコードベースに混在し、規模が大きくなるにつれて変更の影響範囲が読みにくくなる。一方、全体を複数のサービスの組み合わせで構成する「マイクロサービス」方式は、サービスごとに異なるサーバで稼働させることを前提とするため、分散システム特有の複雑さが生じる。サービス間通信の遅延や障害の伝播、分散トランザクションの管理などである。
モジュラーモノリスはこの二つの中間に位置する構成であり、プロセスは一つのまま保ちつつ、コード上の境界を厳密に引くことで保守性を確保する。モジュール間の境界はAPIなどのインターフェースとして明示的に定義され、あるモジュールが別のモジュールの内部実装に直接依存することを禁じる。
例えば、商品の受発注システムを「注文」「在庫」「顧客」などのそれぞれ独立したモジュールの組み合わせとして設計し、互いに公開されたインターフェース経由でのみやり取りする。このルールを守ることで、特定のモジュールだけを修正したりテストすることが容易になり、チームが担当領域を分けて並行して開発を進めることができる。
アプリケーションの展開(デプロイ)は単一のプロセスとして行われるため、分散システムに必要なコンテナオーケストレーションなどの運用インフラは必要ない。データベースも原則として一つを共有するため、トランザクション管理が単純になる。開発初期や中規模のシステムでは、マイクロサービスを採用するよりも運用コストを低く抑えられる場合が多い。
なお、開発が進んで規模が大きくなり、スケーリングやチーム分割の必要が生じた際には、すでに引かれたモジュール境界をサービス境界として転用し、マイクロサービスへ段階的に移行することもできる。境界設計の精度が低いまま移行を試みると分割コストが高くなるため、ドメイン駆動設計(DDD)の境界付けられたコンテキストの考え方と組み合わせて設計されることが多い。