今日の開発チームは、ますます建築上のジレンマに直面しています。 マイクロサービスとしてシステムを構築するか、モジュール式のモノリスから始めるか？ 近年、このテーマに関する記事が数百件書かれていますが、実際にはすべてが黒と白ではありません。誇張することなく、正直に考えてみましょう。
モジュール式モノリスとは何ですか？
モジュール式モノリスとは 単一のアプリケーションコードは明確なドメインモジュール（たとえば、「支払い」、「プロファイル」、「レポート」）に分割されています。すべてが1つのプロセス、1つのデータベース、1つのデプロイユニットとして実行されます。
長所：
開発とデバッグが簡単です。
インフラのオーバーヘッドがない。
トランザクションは「箱から」動作します。
開発者を雇うのが簡単です。
短所：
システムの成長に伴い、接続性が向上します。
リリースは完全に行わなければなりません。
個々のモジュールをスケールするのがより難しい。
マイクロサービスとは
マイクロサービスとは 独立したサービスのセット、それぞれがビジネスロジックの一部を担当し、APIまたはメッセージを介して通信します。
長所：
独立したリリース;
柔軟なスケーリング;
技術的自由。
短所：
インフラストラクチャの複雑性が高い。
複雑なトランザクション（サーガ、結果整合性）
より強力なエンジニアとDevOpsプロセスが必要です。
モジュール式モノリスを選択するタイミング
スタートアップまたはMVP — 速度が何よりも重要です。
小規模チーム：2〜5人の開発者が簡単に対応できます。
過度の負荷のない製品。
コードに規律が欲しい。
マイクロサービスはいつですか？
システムは成長し、負荷がかかっています。
大規模チーム（50人以上）
地理的分布
柔軟なスタック要件。
公正な選考方法
質問 | 答えが「はい」の場合→ | 答えが「いいえ」の場合→ |
|---|---|---|
製品を迅速に市場に出す必要がありますか？ | モジュール式モノリス | マイクロサービスを検討する |
負荷の異なる独立したドメインはありますか？ | マイクロサービス | モジュール式モノリス |
チームは小さいですか（10人以下）？ | モジュール式モノリス | マイクロサービス（プロセスが成熟している場合） |
技術的な自由が必要ですか？ | マイクロサービス | モジュール式モノリス |
複雑なインフラストラクチャをサポートした経験はありませんか？ | モジュール式モノリス | マイクロサービス（ただしDevOpsを採用） |
合計
モジュール式モノリス これは素晴らしい出発点です。アーキテクチャを統制し、余分な複雑さを追加しません。 マイクロサービス — システムとチームが実際に準備ができている場合にのみ正当化されるスケーリングツール。
重要なのは、手段と目的を混同しないことです。アーキテクチャはビジネスを妨げるのではなく、ビジネスを支援する必要があります。
私たちの Telegramチャンネル コディカ 開発の世界からの最新ニュースを共有し、ITにおけるアーキテクチャ、テクノロジー、キャリアについて話し合います。そこで質問をしたり、アドバイスを得たり、志を同じくする人々とチャットしたりできます。
👉 プロジェクトにとって、モジュール式モノリスとマイクロサービスのどちらが良いと思いますか？