のインフラストラクチャの例AWS

このセクションでは、AWSヘキサゴナルアーキテクチャの実装に使用できるアプリケーションのインフラストラクチャを設計する例を示します。最小限の実行可能な製品 (MVP) を構築するためのシンプルなアーキテクチャから始めることをお勧めします。ほとんどのマイクロサービスには、クライアント要求を処理するための単一のエントリポイント、コードを実行するコンピューティングレイヤー、およびデータを保存するためのパーシスタンスレイヤーが必要です。AWS以下のサービスは、六角形アーキテクチャのクライアント、プライマリアダプタ、セカンダリアダプタとしての使用に適しています。

• クライアント:Amazon API Gateway、Amazon Simple Queue Service (Amazon SQS)、Elastic Load Balancing、Amazon EventBridge

• プライマリーアダプタ:AWS Lambda、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

• セカンダリアダプタ:Amazon DynamoDB、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、 EventBridge、、、、、、、、、、、、、、、、、、Amazon S

次のセクションでは、ヘキサゴナルアーキテクチャを詳しく見て、六角アーキテクチャを詳しく見て、ヘキサゴナルアーキテクチャを詳しく見て、六角アーキテクチャを詳しく見て

シンプルに始める

ヘキサゴナルアーキテクチャを使用してアプリケーションを設計する場合は、シンプルなものから始めることをお勧めします。この例では、API Gateway がクライアント (REST API) として使用され、Lambda がプライマリアプター (コンピューティング) として使用され、DynamoDB がセカンダリアプター (パーシスタンス) として使用されます。ゲートウェイクライアントはエントリーポイント（この場合は Lambda ハンドラー）を呼び出します。

このアーキテクチャは完全にサーバーレスであり、アーキテクトは出発点として適しています。コードの管理が容易になり、新しいビジネス要件や非機能要件に適応できるため、ドメイン内のコマンドパターンを使用することをお勧めします。このアーキテクチャは、いくつかの操作だけで簡単なマイクロサービスを構築するには十分かもしれません。

CQRS パターンを適用する

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

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

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

コンテナ、リレーショナルデータベース、外部 API を追加してアーキテクチャを進化させましょう

コンテナは、実行時間の長いタスクに適しています。データスキーマがあらかじめ定義されていて、SQL 言語の利点を活用したい場合は、リレーショナルデータベースを使用することもできます。さらに、ドメインは外部 API と通信する必要があります。アーキテクチャのサンプルを拡張して、次の図に示されているように、アーキテクチャの要件を詳しく見て、アーキテクチャを詳しく見て、アーキテクチャを詳しく見て、アーキテクチャを詳しく見て

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

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

さらにドメインを追加 (ズームアウト)

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

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

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