

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# でのインフラストラクチャの例 AWS
<a name="examples"></a>

このセクションでは、六角形アーキテクチャの実装に使用できる の AWS アプリケーションのインフラストラクチャを設計する例を示します。最小実行可能な製品 (MVP) を構築するためのシンプルなアーキテクチャから始めることをお勧めします。ほとんどのマイクロサービスでは、クライアントリクエストを処理する単一のエントリポイント、コードを実行するコンピューティングレイヤー、データを保存するための永続化レイヤーが必要です。以下の AWS サービスは、六角形アーキテクチャのクライアント、プライマリアダプター、セカンダリアダプターとして使用するのに最適です。
+ **クライアント:** Amazon API Gateway、Amazon Simple Queue Service (Amazon SQS)、Elastic Load Balancing、Amazon EventBridge
+ **プライマリアダプター:** AWS Lambda、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Compute Cloud (Amazon EC2)
+ **セカンダリアダプター:** Amazon DynamoDB、Amazon Relational Database Service (Amazon RDS)、Amazon Aurora、API Gateway、Amazon SQS、Elastic Load Balancing、EventBridge、Amazon Simple Notification Service (Amazon SNS)

以下のセクションでは、六角形アーキテクチャのコンテキストにおけるこれらのサービスについて詳しく説明します。

## シンプルに開始する
<a name="start-simple"></a>

六角形アーキテクチャを使用してアプリケーションを設計するときは、簡単に開始することをお勧めします。この例では、API Gateway をクライアント (REST API) として使用し、Lambda をプライマリアダプター (コンピューティング) として使用し、DynamoDB をセカンダリアダプター (永続性) として使用します。ゲートウェイクライアントはエントリポイントを呼び出します。この場合は Lambda ハンドラーです。

![\[シンプルな六角形アーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/hexagonal-architectures/images/simple.png)


このアーキテクチャは完全にサーバーレスであり、アーキテクトに良い出発点を与えます。ドメインでコマンドパターンを使用することをお勧めします。これは、コードのメンテナンスが容易になり、新しいビジネス要件や非機能要件に適応するためです。このアーキテクチャは、いくつかのオペレーションでシンプルなマイクロサービスを構築するのに十分です。

## CQRS パターンを適用する
<a name="apply-cqrs"></a>

ドメインのオペレーション数がスケールする場合は、CQRS パターンに切り替えることをお勧めします。次の例を使用して、 で AWS CQRS パターンを完全にサーバーレスアーキテクチャとして適用できます。

![\[六角形アーキテクチャでの CQRS パターンの適用\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/hexagonal-architectures/images/cqrs.png)


この例では、2 つの Lambda ハンドラーを使用します。1 つはクエリ用、もう 1 つはコマンド用です。クエリは、API ゲートウェイをクライアントとして使用して同期的に実行されます。コマンドは、Amazon SQS をクライアントとして使用して非同期的に実行されます。

このアーキテクチャには、複数のクライアント (API Gateway と Amazon SQS) と、対応するエントリポイント (Lambda ハンドラー) によって呼び出される複数のプライマリアダプター (Lambda) が含まれます。すべてのコンポーネントは同じ境界コンテキストに属するため、同じドメイン内にあります。

## コンテナ、リレーショナルデータベース、外部 API を追加してアーキテクチャを進化させる
<a name="evolve"></a>

コンテナは、長時間実行されるタスクに適したオプションです。事前定義されたデータスキーマがあり、SQL 言語の能力を活用する場合は、リレーショナルデータベースを使用することもできます。さらに、ドメインは外部 APIsと通信する必要があります。次の図に示すように、これらの要件をサポートするようにアーキテクチャの例を進化させることができます。

![\[コンテナ、リレーショナルデータベース、外部 API を追加して六角形アーキテクチャを進化させる\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/hexagonal-architectures/images/evolve.png)


この例では、ドメインで長時間実行されるタスクを起動するためのプライマリアダプターとして Amazon ECS を使用します。Amazon EventBridge (クライアント) は、特定のイベントが発生したときに Amazon ECS タスク (エントリポイント) を開始します。このアーキテクチャには、リレーショナルデータを保存するための別のセカンダリアダプターとして Amazon RDS が含まれています。また、外部 API コールを呼び出すためのセカンダリアダプターとして別の API ゲートウェイも追加されます。その結果、アーキテクチャは、1 つのビジネスドメイン内のさまざまな基盤となるコンピューティングレイヤーに依存する複数のプライマリアダプターとセカンダリアダプターを使用します。

ドメインは常に、*ポート*と呼ばれる抽象化を通じて、すべてのプライマリアダプターとセカンダリアダプターと疎結合されます。ドメインは、ポートを使用して外部から必要なものを定義します。ポートを実装するのはアダプターの責任であるため、あるアダプターから別のアダプターに切り替えてもドメインには影響しません。たとえば、ドメインに影響を与えずに新しいアダプターを記述することで、Amazon DynamoDB から Amazon RDS に切り替えることができます。

## さらにドメインを追加する (ズームアウト)
<a name="zoom"></a>

六角形アーキテクチャは、マイクロサービスアーキテクチャの原則とよく一致しています。ここに示したアーキテクチャの例には、単一のドメイン (または境界コンテキスト) が含まれていました。アプリケーションには通常、プライマリアダプターとセカンダリアダプターを介して通信する必要がある複数のドメインが含まれます。各ドメインはマイクロサービスを表し、他のドメインと疎結合されています。

![\[六角形アーキテクチャへのドメインの追加\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/hexagonal-architectures/images/domains.png)


このアーキテクチャでは、各ドメインは異なるコンピューティング環境のセット (複数可) を使用します。(各ドメインには、前の例のように複数のコンピューティング環境がある場合もあります）。各ドメインは、ポートを介して他のドメインと通信するために必要なインターフェイスを定義します。ポートは、プライマリアダプターとセカンダリアダプターを使用して実装されます。これにより、アダプターに変更があった場合、ドメインは影響を受けません。さらに、ドメインは互いに分離されます。

前の図に示すアーキテクチャ例では、Lambda、Amazon EC2、Amazon ECS、 AWS Fargate がプライマリアダプターとして使用されます。API Gateway、Elastic Load Balancing、EventBridge、Amazon SQS はセカンダリアダプターとして使用されます。