モジュラーモノリスアーキテクチャ解説：規律ある構築

モノリシックアーキテクチャが単一でまとまりのない建物であり、マイクロサービスが分散型の都市であるとすると、モジュラーモノリスは、よく整理された、複数階建てのオフィス複合施設です。モノリスのシンプルさを取り入れ、その内部構造に厳格な規律を適用しています。

モジュラーモノリスとは？

モジュラーモノリスは、アプリケーション全体が単一のユニットとしてデプロイされるものの、コードがビジネスドメインに基づいて独立した、明確に定義されたモジュールに分割されるアーキテクチャパターンです。

• 単一デプロイユニット：従来のモノリスと同様に、単一のプロセスとしてデプロイされます（多くの場合、同じデータベースを共有します）
   

• 厳密な境界：モジュールは明確な分離を強制します。「請求」モジュールは、「在庫」モジュールの内部コードやデータベーステーブルを直接呼び出すことはできません。通信は、定義されたパブリックインターフェース（内部API）を通じてのみ行われます
   

• ドメインフォーカス：各モジュールは、特定のドメインの独自のユーザーインターフェース、ビジネスロジック、およびデータアクセスをカプセル化します

規律の良い側面

モジュラーモノリスは、多くの企業にとって素晴らしいバランスを提供します。

• デプロイのシンプルさ：デプロイと管理すべきものがまだ1つしかないため、マイクロサービスの大きな運用上の負担を回避できます
   

• 明確な所有権とメンテナンス：チームは、アプリケーションの他の部分を壊すことを恐れることなく、モジュールを所有し、作業することができ、内部の俊敏性を劇的に向上させます
   

• リファクタリングの安全性：明確で強制的なモジュールの境界により、モジュール内での大規模なリファクタリングやテクノロジーのアップグレードがはるかに安全になります
   

• 容易な足がかり：境界がすでに確立されているため、後でモジュールを完全に独立したマイクロサービスに抽出することがはるかに簡単です（多くの場合、Strangler Figパターンを使用）。

制御された成長の課題

最大のマイクロサービスの複雑さを回避しますが、それでも制限があります。

• 必須のスケーリング：単一のユニットであるため、1つのモジュールのみが負荷がかかっている場合でも、すべてのモノリスをスケーリングする必要があります
   

• 内部通信は依然としてローカル：モジュールは単純な関数呼び出し（ネットワーク呼び出しではない）を介して通信するため、クラッシュしたモジュールはアプリケーション全体をダウンさせる可能性があります
   

• 規律が必要：境界を強制するための自動化されたツール（アーキテクチャテストやパッケージ管理ユーティリティなど）がないと、モジュラーモノリスは、従来型の緊密に結合されたモノリスに簡単に劣化する可能性があります
   

• 共有リソース：共有データベースは、注意深く管理しないと、依然として対立とボトルネックの要因になる可能性があります。

いつ意味をなすのか？

このアーキテクチャは、成長を予測しているが、まだ分散システムの高い複雑さとコストを正当化できない新規または中規模のアプリケーションに最適です。また、デプロイの速度とシンプルさを重視しながら、クリーンで、整理され、進化可能なコードベースを維持したいチームにも最適です。