注文ライフサイクル状態図

ダイアグラムエンジニアリング · 注文管理1つのプロンプトから作成
読み取り専用プレビュー

プロンプト

Eコマースの注文ライフサイクルの状態図を作成してください

自分用に作り直す

フレームワークについて

注文のステータスを変えるイベントを確認する

この例には、Placed、Processing、Shipped、Delivered、Cancelled、Refundedという6つの名前付き状態が含まれています。メインルートは、支払いの確認、倉庫での出荷処理、配送業者による配達を受けて進みます。顧客がキャンセルした場合はPlacedから、在庫がない場合はProcessingからキャンセルできます。

Deliveredには終了遷移と、Return requestedというラベルが付いたRefundedへの分岐の両方があります。この直接的な遷移は簡略化されたものです。返品承認、検品、返金処理といった個別の状態は設けられていません。CancelledとRefundedも終了マーカーに接続されています。

このマップを使って、これらの遷移を実際の注文ルールと比較してください。システムが実際に記録するイベントを示したうえで、不足している中間状態を追加し、各ステータスから許可する遷移を決めましょう。

含まれる内容

得られるもの

  • 6つの注文状態と各遷移ラベル
  • 処理と出荷を経て注文配置から配送まで進むパス
  • 異なるトリガーイベントを持つ2つのキャンセル経路
  • 返品に関する検討用のDeliveredからRefundedへの直接分岐
ダイアグラム

注文ライフサイクル状態図

状態図注文管理ワークフローUMLEコマース

✦ Free preview · Sign in to use

よくある質問

よくある質問

この例では、注文をいつキャンセルできますか?

このチャートでは、顧客都合のキャンセルはPlacedから、在庫切れによるキャンセルはProcessingから実行できます。Shippedからのキャンセル遷移は表示されていません。

返品リクエストによって、返金はすぐに完了しますか?

このサンプルでは直接的な遷移を描いているため、複数の可能な手順を省略しています。プロセスで返品と返金を追跡する場合は、返品と返金の状態を分けて指定してください。

これを注文ステータスのテスト定義に利用できますか?

ラベル付きの遷移を確認すべきケースとして利用し、不足している条件や拒否される遷移を指定してください。この図自体がアプリケーションの注文ルールを強制するわけではありません。

注文ライフサイクル状態図

無料で開始。クレジットカード不要。

Free preview · Sign in to use