園芸用品の通信販売会社の注文受付と出荷状況の管理

架空の園芸用品の通信販売会社で、通販サイトで確定した注文を受け付け、梱包や配送の結果に合わせて注文の状況を更新する業務を支えます。注文は商品・配送・決済の各サービスで確かめてからDynamoDBに保存し、配送や倉庫のサービスにはAPI Gatewayで注文の内容を提供します。変更はDynamoDB StreamsからEventBridgeへ知らせ、Lambdaのエラーが増えるとCloudWatchとSNSで担当者に通知します。業務の想定はIceShoreが用意した架空の事例です（実在の会社・システムではありません）。出典: https://github.com/aws-samples/aws-serverless-ecommerce-platform/tree/3b9ef36dd3e338c8ab697c2bcb1b672e064e303c （著作権表示: Copyright 2019 Amazon.com, Inc. or its affiliates. All Rights Reserved.／ライセンス: MIT No Attribution（MIT-0））。元のファイルを変更せずに掲載しています。

アクター

通販サイトの画面側サービス
配送・倉庫の社内サービス
商品サービス
配送サービス
決済サービス
通販システム共通のイベントバス
通販システム担当

ユースケース

購入者が確定した注文の受け付け
配送・倉庫のサービスによる注文の参照
梱包と配送の結果による注文の状況の更新
注文処理のエラーの通知

この構成図は、架空の園芸用品の通信販売会社で、通販サイトで確定した注文を受け付け、梱包や配送の結果に合わせて注文の状況を更新する業務を支えます。注文を受け付けるときは、商品・配送・決済の各サービスで内容を確かめてからAmazon DynamoDBに保存します。注文の変更は、DynamoDB Streamsを通じて通販システム共通のEventBridgeのイベントバスへ知らせます。業務の想定はIceShoreが用意した架空の事例です。元にしたのは、aws-samples/aws-serverless-ecommerce-platformのorders/template.yaml（ライセンスMIT-0）です。

注文の受け付けと状況の管理を支えるリソース

中心となるのは、DynamoDBの注文テーブルです。キーはorderIdです。userIdとcreatedDateによるGSI「user」を持ち、ストリームはNEW_AND_OLD_IMAGESで有効になっています。Lambda関数は4つあります。・CreateOrder：注文を受け付けます。・GetOrder：API Gateway（REGIONAL、ステージprod）のGET /backend/{orderId}に応答します。・TableUpdate：テーブルの変更をイベントとして送ります。・OnEvents：配送・倉庫のイベントを受けて、注文の状況を更新します。テンプレートの外にあるものは、外部システムとして描いています。CreateOrderを呼び出す通販サイトの画面側サービス、注文を参照する配送・倉庫の社内サービス、商品・配送・決済の各サービス、通販システム共通のイベントバスです。処理に失敗したレコードやイベントは、デッドレターキュー（SQS、ネストしたスタックで定義）へ送られます。CloudWatchのアラームは、SNSのトピックを通じて通販システム担当へ知らせます。

注文の受け付けから出荷、エラーの通知までの流れ

構成図には4つのユースケースがあります。

「購入者が確定した注文の受け付け」では、購入者が注文を確定すると、画面側サービスがCreateOrder関数を直接呼び出します。CreateOrderは商品・配送・決済の各サービスをPOSTで呼び出して注文の内容を確かめ、PutItemで注文テーブルへ保存します。この書き込みでDynamoDB StreamsからTableUpdate関数が起動し、注文のイベント（source: ecommerce.orders）をイベントバスへ送ります。

「配送・倉庫のサービスによる注文の参照」では、配送・倉庫のサービスが出荷の準備のためにGET /backend/{orderId}を呼び出します。GetOrder関数は、GetItemで注文を読み出して返します。

「梱包と配送の結果による注文の状況の更新」では、EventBridgeのルールがイベントをOnEvents関数へ届けます。届けるのは、配送のイベント（DeliveryCompleted／DeliveryFailed）と倉庫のイベント（PackageCreated／PackagingFailed）です。OnEventsは注文の状況を更新します。IAMポリシーで、OnEventsが読み書きできる属性はorderId・products・statusに限られています。この変更も、TableUpdateによって注文のイベントとして送り直されます。

「注文処理のエラーの通知」では、CloudWatchのアラームが閾値を超えたときにSNSのトピックへ知らせます。テンプレートのアラームの対象は、Lambdaのエラー・スロットル、API Gatewayの4XX・5XX・遅延、DynamoDBのエラー、注文数の異常検知などです。構成図では、代表としてLambdaErrorsAlarmを起点に描いています。

月に1万5千〜6万件という注文の数や、春に注文が増えることは、この架空の業務に合わせて置いた想定です。

元のIaC（orders/template.yaml）

元になったのは、aws-samples/aws-serverless-ecommerce-platform（コミット3b9ef36dd3e338c8ab697c2bcb1b672e064e303c、MIT-0）のorders/template.yamlです。Transform: AWS::Serverless-2016-10-31を使う、SAM形式のCloudFormationテンプレートです。主なリソースの型は次のとおりです。・AWS::DynamoDB::Table（Table）・AWS::Serverless::Function（CreateOrderFunction、GetOrderFunction、TableUpdateFunction、OnEventsFunction）・AWS::Serverless::Api（Api）・AWS::CloudFormation::Stack（DeadLetterQueue。shared/templates/dlq.yamlを参照）・AWS::SNS::Topic（AlarmTopic）・AWS::CloudWatch::Alarm（各種アラーム）・AWS::CloudWatch::AnomalyDetector ・AWS::CloudWatch::Dashboard ・AWS::Logs::LogGroup ・AWS::SSM::Parameter テンプレートは、各APIのURL・ARNとイベントバスの名前・ARNを、SSMパラメータ経由で受け取ります。また、テーブル名、CreateOrder関数のARN、APIのURL・ARNを、SSMパラメータとして公開します。

この構成図の作り方と、業務の想定について

この構成図は、公開リポジトリにある上記のIaCをもとに作りました。まずAIがテンプレートを読み、IceShore（アイスショア）のMCP（Model Context Protocol）を通して、構成図の記述（ADL形式のデータ）を書きました。IceShoreは、その記述から構成図を描画しています。テンプレートに現れない呼び出し元（画面側サービスや配送・倉庫の社内サービス）と、通知を受ける通販システム担当は、ADLの中でアクターとして記述しています。呼び出し元は外部システムの型、担当者は人の型です。SNSの購読先は、テンプレートの外で設定される前提です。元のテンプレートは、汎用のECプラットフォームの注文サービスです。園芸用品の通信販売会社という業務の想定は、IceShoreが用意した架空の事例です。実在の会社やシステムではありません。

よくある質問

SAM（AWS::Serverless::Functionなど）を使ったCloudFormationテンプレートでも、構成図にできますか？

はい。この構成図の元になったorders/template.yamlは、Transform: AWS::Serverless-2016-10-31を使うSAM形式のテンプレートです。描くときに使ったのは、AWS::Serverless::FunctionやAWS::Serverless::Apiと、そのイベント設定（Api、DynamoDB、CloudWatchEvent）です。そこから、関数・API・ストリーム・イベントルールのつながりを描いています。

テンプレートに定義のない商品・配送・決済のサービスやイベントバスが、なぜ図に出てくるのですか？

これらは別のスタックにあります。このテンプレートは、SSMパラメータ（AWS::SSM::Parameter::Value<String>）でURLやARNを受け取って参照しています。CreateOrder関数のIAMポリシーにも各APIへのexecute-api:Invoke（POST）があるため、構成図では外部システムとして描いています。この想定では、それぞれを園芸用品の商品情報と価格、配送先と送料、支払いを確かめる自社のサービスとしています。

デッドレターキューには何が送られますか？

テンプレート上では2種類あります。1つは、TableUpdate関数のDynamoDBストリーム処理に失敗したレコードです（OnFailureの送り先）。もう1つは、OnEvents関数の非同期呼び出しに失敗したイベントです（EventInvokeConfigのOnFailure）。キュー自体は、ネストしたスタック（shared/templates/dlq.yaml）で定義されています。このファイルは対象のテンプレートに含まれないため、中身は構成図に描いていません。

出典: aws-samples/aws-serverless-ecommerce-platform（MIT-0）

IaC を読み込むと、あなたのシステムでもこのような構成図を作れます。 IceShore とは