論理アーキテクチャと物理アーキテクチャ

この時点で、論理アーキテクチャと物理アーキテクチャの違い、およびマイクロサービス ベースのアプリケーションの設計にどのように適用されるかを停止して説明すると便利です。

まず、マイクロサービスを構築するには、特定のテクノロジを使用する必要はありません。 たとえば、Docker コンテナーは、マイクロサービス ベースのアーキテクチャを作成するために必須ではありません。 これらのマイクロサービスは、プレーン プロセスとして実行することもできます。 マイクロサービスは論理アーキテクチャです。

さらに、マイクロサービスを 1 つのサービス、プロセス、またはコンテナーとして物理的に実装できる場合でも (わかりやすくするために、 これは eShopOnContainers の初期バージョンで採用されたアプローチです)、ビジネス マイクロサービスと物理サービスまたはコンテナーの間のこのパリティは、数十から数百のサービスで構成される大規模で複雑なアプリケーションを構築するときに必ずしも必要とは限りません。

ここでは、アプリケーションの論理アーキテクチャと物理アーキテクチャの間に違いがあります。 システムの論理アーキテクチャと論理境界は、必ずしも物理アーキテクチャやデプロイメントアーキテクチャに直接 1 対 1 で対応するわけではありません。 これは発生する可能性がありますが、多くの場合は発生しません。

あなたは特定のビジネス マイクロサービスや有界コンテキストを識別したかもしれませんが、それらを実装する最善の方法が常にビジネス マイクロサービスごとに1つのサービス（例えば、ASP.NET Web API）や1つのDockerコンテナーを作成することであるわけではありません。 各ビジネス マイクロサービスを 1 つのサービスまたはコンテナーを使用して実装する必要があるというルールを持つことは、厳格すぎます。

そのため、ビジネス マイクロサービスまたは有界コンテキストは、物理アーキテクチャと一致する (または一致しない) 論理アーキテクチャです。 重要なポイントは、コードと状態を個別にバージョン管理、デプロイ、スケーリングできるようにすることで、ビジネス マイクロサービスまたは有界コンテキストが自律的である必要があるということです。

図 4-8 に示すように、カタログ ビジネス マイクロサービスは複数のサービスまたはプロセスで構成できます。 これらは、複数の ASP.NET Web API サービス、または HTTP やその他のプロトコルを使用する他の種類のサービスです。 さらに重要なのは、同じビジネス ドメインに関してこれらのサービスがまとまりがある限り、サービスは同じデータを共有できることです。

図 4-8 複数の物理サービスを備えたビジネス マイクロサービス

Web API サービスは Search サービスと同じデータを対象としているため、この例のサービスは同じデータ モデルを共有します。 そのため、ビジネス マイクロサービスの物理的な実装では、必要に応じて各内部サービスをスケールアップまたはスケールダウンできるように、その機能を分割します。 Web API サービスでは通常、Search サービスよりも多くのインスタンスが必要な場合と、その逆が必要な場合があります。

つまり、マイクロサービスの論理アーキテクチャが、物理デプロイ アーキテクチャと常に一致する必要はありません。 このガイドでは、マイクロサービスについて説明するたびに、1 つ以上の (物理) サービスにマップできるビジネスマイクロサービスまたは論理マイクロサービスを意味します。 ほとんどの場合、これは 1 つのサービスですが、より多くの場合があります。