チームパターンごとのサービス

チームごとのサービスパターンでは、モノリスをビジネス機能やサービスごとに分解するのではなく、個々のチームが管理するマイクロサービスに分割します。各チームはビジネス機能を担当し、その機能のコードベースを所有しています。チームはサービスを独自に開発、テスト、デプロイ、スケールし、主に他のチームとやり取りして API の交渉を行います。各マイクロサービスを 1 つのチームに割り当てることをお勧めします。ただし、チームの規模が大きい場合は、同じチーム構造内で複数のサブチームが別々のマイクロサービスを所有することもできます。以下の表では、このパターンを使用する利点と欠点について説明します。

利点	欠点
チームは最小限の調整で独立して行動します。 コードベースとマイクロサービスは複数のチームで共有されません。 チームは製品の特徴量をすばやく革新し、繰り返し開発できます。 チームが異なれば、使用するテクノロジー、フレームワーク、プログラミング言語も異なります。重要: これらは明確に定義され安定したパブリック API の背後に隠されるべきです。	エンドユーザーの機能やビジネス機能に合わせてチームを連携させるのは難しい場合があります。 特にチーム間に循環的な依存関係がある場合は、より大規模で協調的なアプリケーションを提供するために、さらなる努力が必要です。

次の図は、モノリスをマイクロサービスに分割して、個々のチームが管理、保守、提供する方法を示しています。