正解: B

モノリスの最大の利点は初期開発とデプロイのシンプルさです。単一のコードベース、単一のデプロイユニット、単一のデータベースにより、開発初期は高い生産性を発揮します。分散システムの複雑さ（ネットワーク遅延、データ整合性、サービス間通信）を考慮する必要がありません。ただし、システムが成長するにつれ、この利点は逆に制約となります。

正解: B

技術的負債ヒートマップは「変更頻度」と「バグ発生率」の組み合わせが最も効果的です。頻繁に変更されるファイルでバグが多いということは、そのコードが不安定で理解しにくい状態にあることを示します。Adam Tornhill の「Your Code as a Crime Scene」で提唱されたこのアプローチは、コード行数やカバレッジよりも実際のリスクを正確に反映します。循環的複雑度を加えるとさらに精度が向上します。

正解: B

God Object は単一のクラスが過剰な責務を持つアンチパターンです。典型的な兆候は、1,000行以上のクラス、20以上のメソッド、多数の異なるドメイン概念の混在です。これにより、変更の影響範囲が予測困難になり、テストが複雑化し、複数チームのマージコンフリクトが頻発します。解決策は、Single Responsibility Principle に基づくクラスの分割です。

正解: B

循環依存の最大の問題は、モジュールを独立してテスト・デプロイできなくなることです。A が B に依存し、B が A に依存する場合、A を変更するには B のことも考慮する必要があり、その逆も同様です。これにより、テスト時にモック/スタブが複雑化し、デプロイ時に両方を同時にリリースする必要が生じます。マイクロサービス化の際、この循環依存の解消は最も重要な前提条件の一つです。

正解: B

Strangler Fig パターンは、絞め殺しのイチジク（strangler fig）が宿主の木を徐々に覆い尽くす様子にちなんだパターンです。新機能は新しいサービスとして構築し、既存のモノリスの機能を段階的に新サービスに移行します。APIゲートウェイやリバースプロキシでルーティングを制御し、リスクを最小化しながら移行を進めます。ビッグバンリライトと比較して、失敗のリスクが大幅に低いアプローチです。

正解: A

結合度は低い方から順に「データ結合（必要なデータのみ渡す）→ スタンプ結合（データ構造を渡すが一部しか使わない）→ 制御結合（制御フラグで動作を変える）→ 共通結合（グローバルデータを共有）→ 内容結合（他モジュールの内部を直接参照）」です。マイクロサービス設計では、サービス間の結合をデータ結合に保つことが重要です。

正解: B

移行を検討すべき最も重要なシグナルは、デプロイ頻度の低下とチーム間のコンフリクト頻発です。これは組織のスケーラビリティの限界を示しており、ビジネスの成長速度に技術が追いつけなくなっている状態です。コード行数や使用言語は直接的な移行理由にはなりません。クラウド移行はモノリスのままでも可能です。マイクロサービス化は「組織的な問題を技術的に解決する」アプローチです。

正解: C

共有データベースの最大の問題は、スキーマ変更の影響範囲です。1つのテーブルにカラムを追加するだけでも、そのテーブルを参照する全てのサービス/モジュールに影響が及びます。これにより、独立したデプロイが不可能になり、全チームの調整が必要なリリーストレインを強いられます。Database per Service パターンで各サービスが自身のデータストアを持つことで、この問題を解決します。