疎結合と密結合は、友達関係で例えると分かりやすいです。密結合は、いつも一緒にいないと何もできない親友同士。疎結合は、普段は別々だけど、必要な時に協力できるサークルの仲間のような関係です。システム開発では、この関係性を意識することで、変更に強く、柔軟なシステムを作れます。
面接官：疎結合 / 密結合について説明してください。
私：疎結合とは、システム内の各要素が互いに依存しない状態のことです。一方、密結合は、要素同士が強く依存している状態を指します。
以前のプロジェクトで、ECサイトの注文処理システムをマイクロサービス化する際に、疎結合を意識して設計しました。当初はモノリシックなシステムで、注文処理、在庫管理、決済処理がすべて一つのアプリケーションに組み込まれており、小さな変更でも全体に影響が出ていました。
そこで、各機能をマイクロサービスとして独立させ、メッセージキュー（RabbitMQ）を使って非同期に連携するように変更しました。例えば、注文サービスが完了したら、メッセージキューにイベントを発行し、在庫管理サービスがそのイベントを購読して在庫を更新する、という流れです。
この結果、各サービスの独立性が高まり、個別に開発・デプロイできるようになりました。 また、一部のサービスに障害が発生しても、他のサービスに影響が及ぶリスクを最小限に抑えることができました。
現役エンジニアによる深掘り解説
疎結合のメリット
高い保守性: 各コンポーネントが独立しているため、変更や修正が容易に行えます。あるコンポーネントの変更が他のコンポーネントに影響を与えにくいため、システム全体の安定性を保ちながら、柔軟な開発が可能です。
高い拡張性: 新しい機能やサービスを追加する際に、既存のシステムに大きな変更を加える必要がありません。独立したコンポーネントとして追加できるため、スケーラビリティに優れています。
高い再利用性: コンポーネントが独立しているため、他のシステムやプロジェクトで再利用しやすくなります。開発効率の向上に貢献します。
耐障害性の向上: 一つのコンポーネントに障害が発生しても、他のコンポーネントに影響が及びにくいため、システム全体の可用性を高めることができます。
疎結合のデメリット
複雑性の増加: コンポーネント間の連携が複雑になる場合があります。メッセージキューなどのミドルウェアの導入や、API設計など、より高度な設計スキルが必要になります。
パフォーマンスの低下: コンポーネント間の通信にオーバーヘッドが発生する場合があります。特に、ネットワークを介した通信を行う場合には、レイテンシが問題となることがあります。
開発コストの増加: 疎結合なシステムを構築するには、より多くの時間と労力がかかる場合があります。各コンポーネントのインターフェース設計やテストなど、より詳細な検討が必要になります。
密結合のメリット
開発が容易: コンポーネント間の依存関係が強い分、実装がシンプルになる場合があります。特に、小規模なシステムや、開発期間が限られている場合には、有効な選択肢となります。
パフォーマンスが高い: コンポーネント間の通信が高速に行える場合があります。同一プロセス内で処理を行う場合など、オーバーヘッドを最小限に抑えることができます。
密結合のデメリット
保守性が低い: あるコンポーネントを変更すると、他のコンポーネントにも影響が及ぶ可能性が高いため、変更や修正が困難になります。
拡張性が低い: 新しい機能やサービスを追加する際に、既存のシステムに大きな変更を加える必要が生じる場合があります。
再利用性が低い: コンポーネントが他のシステムやプロジェクトで再利用しにくくなります。
耐障害性が低い: 一つのコンポーネントに障害が発生すると、他のコンポーネントにも影響が及びやすく、システム全体の可用性が低下する可能性があります。
⚠️ 面接突破のワンポイント
- 面接では、疎結合/密結合のそれぞれのメリット・デメリットを理解しているか確認されます。自身の経験に基づいて、具体的な事例を交えて説明できるように準備しましょう。
- 疎結合を実現するための具体的な技術（メッセージキュー、API Gatewayなど）についても理解しておくと、より深い議論に対応できます。
