モジュラーモノリスとは何か？クリーンな境界、1つのdeploy

モジュラーモノリスは、明示的なインターフェースを通じて通信する、よく境界付けられた内部モジュールに編成された単一のデプロイ可能なアプリケーションです。

モジュラーモノリスは両方の世界の最良を得ようとします。1つのdeployという運用上のシンプルさと、マイクロサービスのクリーンな境界です。モジュールは互いの内部に手を伸ばすのではなく、定義されたインターフェースを通じて通信するため、codebaseは分散システムの税金を払うことなく規律を保ちます。

核心となる考え方

1つのデプロイ可能なartifactを保ちますが、その内部でモジュール境界を強制します。各モジュールは自身のデータを所有し、狭いインターフェースを公開します。他のモジュールはそのインターフェースを呼び出し、決して内部を呼び出しません。境界は、ネットワークホップではなく、ツールによって強制されるコードの規約です。

魅力的な理由

運用する1つのdeployと1つのruntime。
チーム間の明確な所有権の線引き。
後で必要ならマイクロサービスを抽出するための自然な継ぎ目。
モジュール間でネットワークレイテンシや分散障害がない。

境界の強制

境界は、何かがそれをチェックする場合にのみ保たれます。アーキテクチャテスト、lintルール、またはpipeline内の依存方向チェックが、あるモジュールが別のモジュールの内部をimportしたときにbuildを失敗させます。そのgateがなければ、モジュラーモノリスは静かにもつれたものへと衰退します。

CI/CDの観点

依然として1つのpipelineを持ちますが、モジュール構造により境界チェックを追加でき、適切なbuildツールがあれば変更されたモジュールに影響を受けるテストだけを実行できます。それにより、多くのpipelineに分割することなく、大きなモノリシックbuildを速く保てます。

移行の入り口

モジュールはすでにクリーンなインターフェースを持っているため、後で1つを独自のサービスに昇格させることは、はるかに苦痛が少なくなります。多くのチームは、どのモジュールが本当に別のマイクロサービスである必要があるかを判断する前のステップとして、意図的にモジュラーモノリスを使います。

1つのpipelineでの速いフィードバック

影響を受けるモジュールのテスト選択は、runnerが速く起動する場合にのみ報われます。遅いcold startは節約した時間を消し去ります。warmなマネージドrunner（Latchkeyが提供するような）は、そのフィードバックループをタイトに保ちます。

重要なポイント

モジュラーモノリスは、内部モジュール境界が強制された1つのdeployです。
境界はpipelineでチェックされなければ、時間とともに浸食されます。
初期の分散コストなしに、マイクロサービスへの低リスクな入り口を提供します。