私が直面した技術(shù)面接の 1 つで、ユーザーがサードパーティ プロバイダーからインターネット クレジットを購(gòu)入できる電子商取引システムを設(shè)計(jì)するように求められました。

私は自信を持って、利用可能なパッケージを表示し、ユーザーにパッケージを選択させ、外部ゲートウェイ経由で支払いを処理し、プロバイダーと対話してクレジットを提供するという単純な解決策を提案しました。しかし、ユーザーが支払いを完了した後にプロバイダーの在庫(kù)がなくなるなどの障害シナリオについて尋ねられたとき、私の設(shè)計(jì)にはそのような問(wèn)題を効果的に処理するための回復(fù)力が欠けていることに気づきました。

數(shù)週間前、私はフラッシュセールシステムと在庫(kù)予約パターン、特に在庫(kù)予約戦略に焦點(diǎn)を當(dāng)てた調(diào)査を?qū)g施しました。フラッシュセールでは需要が高く在庫(kù)が限られていることが多いため、システムの安定性を維持し、顧客の期待を管理するための高度なメカニズムが必要です。私が発見したコンセプトの 1 つは、ピーク時(shí)の過(guò)剰販売を防ぐための一時(shí)的な在庫(kù)予約です。

この調(diào)査を見て、私は面接での経験を思い出しました。これらの在庫(kù)予約戦略を適用すれば、最初の設(shè)計(jì)の欠點(diǎn)に対処できる可能性があることに気づきました。チェックアウトプロセス中に在庫(kù)の一時(shí)的な保留を組み込むことで、システムはプロバイダーの在庫(kù)が枯渇するシナリオを効果的に処理できます。

この研究文書では、私の研究から得られた洞察を共有し、インターネット クレジット購(gòu)入システムを設(shè)計(jì)するための洗練されたアプローチを提案することを目的としています。在庫(kù)予約戦略を統(tǒng)合することで、シームレスなエクスペリエンスを提供しながら、さまざまな障害シナリオに対応できる堅(jiān)牢かつユーザーフレンドリーなプラットフォームを構(gòu)築できます。

1. 主要な設(shè)計(jì)上の考慮事項(xiàng)

インターネット クレジット購(gòu)入システムを設(shè)計(jì)する場(chǎng)合、シームレスで安全で楽しいユーザー エクスペリエンスを確保するために考慮すべき重要な要素がいくつかあります。それらを詳しく見てみましょう:

1.1 クォータ管理

• リアルタイムのクォータ検証: ユーザーが誤って利用できないオプションを選択しないように、システムはインターネット クレジット パッケージの在庫(kù)があるかどうかを即座に確認(rèn)します。
• 一時(shí)的な割り當(dāng)て予約: 選択したパッケージを短期間保持するメカニズムを追加し、ユーザーが商品を紛失するリスクなしに購(gòu)入を完了するのに十分な時(shí)間を與えます。
• クォータの競(jìng)合の処理: 複數(shù)のユーザーが同時(shí)に同じパッケージを購(gòu)入しようとする狀況を管理し、公平な割り當(dāng)てを確保するための戦略を策定します。
• パッケージ情報(bào)のキャッシュ管理: ユーザーが常に正確な詳細(xì)と可用性を確認(rèn)できるように、キャッシュ データを正確かつ最新に保ちます。

1.2 支払い処理

• 安全な支払い処理: 取引中にユーザーの支払い詳細(xì)を保護(hù)するための強(qiáng)力なセキュリティ対策を?qū)g裝します。
• 支払い保護(hù)のためのエスクロー システム: エスクロー サービスを使用してクレジットが配信されるまで資金を保持し、購(gòu)入者とプロバイダーの両方を安全に保ちます。
• 支払いゲートウェイの統(tǒng)合: システムが信頼できる支払いゲートウェイにスムーズに接続して、手間のかからない取引を確保します。
• 返金メカニズム: 支払いが失敗した場(chǎng)合やキャンセルされた場(chǎng)合に返金を行うための、明確で使いやすいプロセスを作成します。

1.3 プロバイダーの統(tǒng)合

• システムの可用性: 信頼できるシステムを備えたプロバイダーと提攜して、中斷なく購(gòu)入が処理されるようにします。
• API の信頼性: 安定した、十分に文書化された API を提供するプロバイダーと連攜して、シームレスな統(tǒng)合を?qū)g現(xiàn)します。
• サービスアクティベーションの検証: 購(gòu)入したクレジットが適切かつ迅速にアクティベートされていることを確認(rèn)するためのチェックが含まれます。
• エラー処理と再試行: 失敗したプロセスに対する再試行メカニズムを備えた、エラーを迅速に捕捉して解決するためのプロトコルを?qū)g裝します。

1.4 取引の安全性

• マネー フロー制御: 取引が正常に完了した場(chǎng)合にのみ資金が解放されるようにします。
• トランザクションの一貫性: エラーを防ぐために、すべてのトランザクションの正確かつ一貫した記録を保持します。
• ロールバック メカニズム: 何か問(wèn)題が発生した場(chǎng)合にトランザクションを元に戻し、ユーザーとシステムの両方を保護(hù)する計(jì)畫を立ててください。
• 監(jiān)査証跡: 詳細(xì)なログを維持して、問(wèn)題を効果的に監(jiān)視し、トラブルシューティングするのに役立ちます。

1.5 ユーザーエクスペリエンス

• 明確なエラー メッセージ: 発生した問(wèn)題を解決するための、わかりやすく有益なエラー メッセージをユーザーに提供します。
• 取引ステータスの可視性: ユーザーがリアルタイムで購(gòu)入ステータスを簡(jiǎn)単に追跡できるようにし、透明性を高めます。
• クイックパッケージロード: 利用可能なパッケージを迅速にロードするようにシステムを最適化し、ユーザーの待ち?xí)r間を短縮します。
• リアルタイム更新: トランザクションや利用可能なパッケージの変更や更新をユーザーに迅速に通知します。

これらの考慮事項(xiàng)を考慮することで、効率的、安全、そしてユーザーフレンドリーなインターネット クレジット購(gòu)入システムを設(shè)計(jì)でき、ユーザーの満足度と信頼が高まります。

2. システム設(shè)計(jì)とフロー

上で概説した基本的な考慮事項(xiàng)に基づいて、次のステップでは、これらの原則を堅(jiān)牢で効果的なシステム設(shè)計(jì)に変換します。さまざまなコンポーネント間の相互作用を慎重にマッピングすることで、システムが機(jī)能要件を満たすだけでなく、信頼性と拡張性を維持しながらシームレスなユーザー エクスペリエンスを提供できるようになります。

このセクションでは、システムのアーキテクチャとフローを詳しく説明し、クォータ管理、支払い処理、サービスのアクティベーションなどのコア機(jī)能がどのように連攜して実裝されるかを示します。目的は、それぞれの設(shè)計(jì)上の選択が、潛在的な課題への対処と信頼できる e コマース クレジット購(gòu)入プラットフォームの提供にどのように貢獻(xiàn)するかを強(qiáng)調(diào)することです。

まず、システム フローの概要をフローチャートで視覚化し、ユーザーが最初から最後までシステムとどのように対話するかを説明します。

2.1 フローチャート図

わかりやすくするために、システムのフローは 6 つのフェーズに分割されています。

パッケージ選択フェーズ

• まず、ユーザーはパッケージ選択ページにアクセスし、アプリがキャッシュからパッケージ データを取得します。このデータには、使用可能なパッケージとそのキャッシュされたクォータ情報(bào)が含まれており、ユーザーに表示されます。
• ユーザーはパッケージを選択し、「購(gòu)入」をクリックします。
• そのパッケージの割り當(dāng)てが利用できない場(chǎng)合、アプリは「利用できません」というメッセージを表示し、ユーザーを選択ページに戻します。それ以外の場(chǎng)合、システムはユーザーのクォータを一時(shí)的に予約します。

購(gòu)入の開始

• 次に、システムは選択したパッケージのクォータを予約しようとします。
• 予約が失敗した場(chǎng)合、ユーザーにはエラー メッセージが表示され、選択ページにリダイレクトされます。
• 予約が成功すると、ユーザーは支払いページに進(jìn)みます。

支払い段階

• この段階で、ユーザーは支払いプロセスを開始し、サードパーティの支払いゲートウェイにリダイレクトされます。
• アプリは、支払いステータスを確認(rèn)するために、支払いゲートウェイからの応答 (コールバック) を待ちます。

支払い処理

• アプリは支払いゲートウェイのコールバックをチェックして支払いを検証します。
  • 無(wú)効なコールバックの場(chǎng)合、システムは問(wèn)題をログに記録し、それ以降のステップを停止します。
  • 有効なコールバックの場(chǎng)合:
    • 支払いが失敗した場(chǎng)合: システムは予約されたクォータを解放し、問(wèn)題についてユーザーに通知します。
    • 支払いが成功した場(chǎng)合: システムは支払いを確認(rèn)し、資金をエスクローに保持して、新しい注文を作成します。

サービスのアクティベーション

• 支払いが成功すると、システムはプロバイダーにサービスをアクティブ化するように要求します。
  • アクティベーションが失敗した場(chǎng)合: エスクロー資金は顧客に返金され、失敗について通知されます。
  • アクティベーションが成功した場(chǎng)合: システムはアクティベーションを検証します。
    • 検証が失敗した場(chǎng)合、顧客は返金を受けます。
    • 検証が成功すると、エスクロー資金がプロバイダーに解放され、顧客は通知を受け取ります。

バックグラウンドプロセス

• 定期的なキャッシュ更新: パッケージ データ キャッシュは定期的に更新されます。
• リアルタイムのクォータ更新: クォータの変更は WebSocket 接続経由で通信されます。

このフローは、ユーザーにスムーズで信頼性の高いエクスペリエンスを保証すると同時(shí)に、リソースと潛在的なエラーを効果的に管理します。

2.2 シーケンス図

以下のシーケンス図は、さまざまな役割とコンポーネント間の相互作用を説明するのに役立ちます。

わかりやすくするために、システムのフローは 6 つのフェーズに分割されています。

パッケージ選択フェーズ

• 顧客はまず、パッケージ選択ページにアクセスします。
• フロントエンドはキャッシュからパッケージ データを取得し、キャッシュされたクォータ情報(bào)とともに使用可能なすべてのパッケージを顧客に表示します。

購(gòu)入の開始

• 顧客がパッケージを選択して「購(gòu)入」をクリックすると、フロントエンドは購(gòu)入リクエストをバックエンドに送信します。
• バックエンドはプロバイダーに問(wèn)い合わせて、選択したパッケージのクォータがまだ利用可能かどうかをリアルタイムで確認(rèn)します。
• クォータが利用可能な場(chǎng)合、バックエンドはプロバイダーを使用してクォータを 15 分間一時(shí)的に予約します。
• バックエンドは予約確認(rèn)をフロントエンドに送信し、顧客は支払いページにリダイレクトされます。

支払い段階

• 顧客は支払いページに進(jìn)み、支払いの詳細(xì)を送信します。
• フロントエンドはこの情報(bào)をバックエンドに送信し、バックエンドは支払いゲートウェイとの支払いセッションを初期化します。
• 支払いセッションの準(zhǔn)備が完了すると、バックエンドはセッションの詳細(xì)をフロントエンドと共有します。
• フロントエンドは、支払いを完了するために顧客を支払いゲートウェイにリダイレクトします。

支払い処理

• 顧客は支払いゲートウェイで支払い情報(bào)を入力し、支払いプロセスを完了します。
• 支払いゲートウェイは、コールバックを通じて支払いステータスをバックエンドに通知します。
  • 支払いが成功した場(chǎng)合:
    • バックエンドは、支払いゲートウェイを使用して支払いステータスを確認(rèn)します。
    • 支払いはエスクローで保持され、バックエンドはエスクローの保持を確認(rèn)します。
  • 支払いが失敗した場(chǎng)合:
    • バックエンドは、プロバイダーの予約済みクォータを解放し、支払いステータスを更新して失敗を反映します。
  • 予想時(shí)間內(nèi)にコールバックが受信されない場(chǎng)合:
    • バックエンドは定期的に支払いゲートウェイをポーリングして支払いステータスを確認(rèn)します。支払いが失敗するかタイムアウトになると、バックエンドは予約された割り當(dāng)てを解放します。

サービスのアクティベーション

• 支払いが成功すると、バックエンドはプロバイダーにサービスをアクティブ化するよう要求します。
• プロバイダーはアクティベーション ステータスで応答し、バックエンドはアクティベーションを検証します。
  • アクティベーションが成功した場(chǎng)合:
    • バックエンドはエスクローからプロバイダーへの支払いを解放します。
    • 成功通知が顧客に送信され、サービスの準(zhǔn)備ができたことを知らせます。
  • アクティベーションが失敗した場(chǎng)合:
    • バックエンドはエスクローされた資金を顧客に返金します。
    • お客様に問(wèn)題について通知するために、障害通知が送信されます。

バックグラウンドプロセス

• プロバイダーは、WebSocket 接続を介して、パッケージ クォータに関するリアルタイムの更新をバックエンドに送信します。
• これらの更新により、キャッシュが常に最新であることが保証されるため、顧客は閲覧時(shí)に最も正確なパッケージの在庫(kù)狀況を確認(rèn)できます。

3. 技術(shù)的な実裝

システムのフローと相互作用の概要を説明したので、次はそれらすべてがコードでどのように組み合わされるかを詳しく見ていきます。このセクションでは、実裝を段階的に説明し、注文の管理からプロバイダーや支払いシステムとのやり取りまで、すべてを処理する機(jī)能部分に設(shè)計(jì)がどのように変換されるかを示します。

// Domain Models
@Getter @Setter
@Entity
public class Package {
    @Id
    private String id;
    private String name;
    private BigDecimal price;
    private BigDecimal providerCost;
    private String description;
    private boolean active;
}

@Getter @Setter
@Entity
public class Order {
    @Id
    private String id;
    private String customerId;
    private String packageId;
    private String reservationId;
    private String paymentId;
    private String escrowId;
    private OrderStatus status;
    private BigDecimal amount;
    private BigDecimal providerCost;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
}

@Getter @Setter
@Entity
public class QuotaReservation {
    @Id
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

// Enums
public enum OrderStatus {
    CREATED, RESERVED, PAYMENT_PENDING, PAYMENT_COMPLETED, 
    IN_ESCROW, ACTIVATING, ACTIVATION_FAILED, COMPLETED, REFUNDED
}

public enum ReservationStatus {
    ACTIVE, EXPIRED, USED, CANCELLED
}

これらのクラスの機(jī)能は次のとおりです:

• パッケージ: ここで、ユーザーが購(gòu)入できるインターネット クレジット パッケージを定義します。パッケージ ID、名前、価格、プロバイダーのコスト、説明、パッケージがアクティブかどうかなどの詳細(xì)を追跡します。

• 注文: これはユーザーの購(gòu)入の記録と考えてください。これには、注文 ID、顧客 ID、選択したパッケージ ID などの情報(bào)と、予約 ID、支払い ID、エスクロー ID、注文ステータス、支払い金額、プロバイダー費(fèi)用、タイムスタンプなどの関連詳細(xì)が含まれます。

• QuotaRegistration: パッケージ クォータの一時(shí)的な予約を処理します。予約 ID、関連付けられているパッケージ、有効期限が切れたとき、および現(xiàn)在のステータス (アクティブまたは期限切れなど) を記録します。

• OrderStatus Enum: この列挙型は、CREATED、RESERVED から PAYMENT_PENDING、COMPLETED、さらには REFUNDED まで、注文が通過(guò)できるすべての段階をマップします。

• RegistrationStatus Enum: 同様に、この列挙型はクォータ予約の狀態(tài) (アクティブ、期限切れ、使用中、またはキャンセル済み) を追跡します。

これらのクラスと列挙型は一緒になって、システム內(nèi)のパッケージ、注文、クォータ予約を管理するためのバックボーンを構(gòu)築します。これは、電子商取引機(jī)能を効果的に処理するための、シンプルでありながら構(gòu)造化されたアプローチです。

// Request/Response DTOs
@Getter @Setter
public class OrderRequest {
    private String customerId;
    private String packageId;
    private BigDecimal amount;
}

@Getter @Setter
public class PaymentCallback {
    private String orderId;
    private String paymentId;
    private String status;
    private BigDecimal amount;
    private LocalDateTime timestamp;
}

@Getter @Setter
public class QuotaResponse {
    private String packageId;
    private boolean available;
    private Integer remainingQuota;
    private LocalDateTime timestamp;
}

@Getter @Setter
public class ReservationResponse {
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

@Getter @Setter
public class ActivationResponse {
    private String orderId;
    private boolean success;
    private String activationId;
    private String errorCode;
    private String errorMessage;
}

@Getter @Setter
public class VerificationResponse {
    private String orderId;
    private String activationId;
    private boolean success;
    private String status;
    private LocalDateTime activatedAt;
}

@Getter @Setter
public class PaymentRequest {
    private String orderId;
    private BigDecimal amount;
    private String currency;
    private String customerId;
    private String returnUrl;
    private String callbackUrl;
}

@Getter @Setter
public class PaymentSession {
    private String sessionId;
    private String paymentUrl;
    private LocalDateTime expiresAt;
    private String status;
}

@Getter @Setter
public class EscrowResponse {
    private String id;
    private String paymentId;
    private BigDecimal amount;
    private String status;
    private LocalDateTime createdAt;
}

詳しく見てみましょう:

• OrderRequest: これはすべて、新しい注文を作成するために必要なデータに関するものです。これには、顧客 ID、購(gòu)入したいパッケージ、支払う合計(jì)金額が含まれます。

• PaymentCallback: これは、支払いゲートウェイからの通知と考えてください。支払いを試行すると、注文 ID、支払い ID、ステータス (成功または失敗)、支払金額、支払いがいつ行われたかなどの詳細(xì)が表示されます。

• QuotaResponse: これは、可用性の確認(rèn)に関するものです。パッケージが利用可能かどうか、割り當(dāng)てがどれだけ殘っているか、情報(bào)が最後に更新されたのはいつかを示します。

• RegistrationResponse: パッケージが予約されると、予約 ID、関連するパッケージ、予約の有効期限が切れる時(shí)期、および現(xiàn)在のステータス (アクティブまたは期限切れなど) のすべての詳細(xì)が表示されます。 .

• ActivationResponse: これは、サービスのアクティブ化がどのように行われたかを示します。成功または失敗すると、アクティベーション ID と、問(wèn)題が発生した場(chǎng)合のエラーの詳細(xì)が表示されます。

• VerificationResponse: アクティベーション後、すべてがスムーズに進(jìn)んだかどうかを検証します。これには、注文 ID、アクティベーション ID、成功ステータス、アクティベートされた時(shí)間が含まれます。

• PaymentRequest: 支払いプロセスを開始する前に、この DTO は注文 ID、支払われる金額、通貨、顧客 ID、コールバック URL などの必要な詳細(xì)を収集します。

• PaymentSession: これは、支払いプロセスの開始時(shí)に作成されるものです。これには、セッション ID、支払い URL (ユーザーが支払いに行く場(chǎng)所)、有効期限が切れる時(shí)期、およびセッション ステータスが含まれます。

• EscrowResponse: 資金がエスクローに保持されている場(chǎng)合、エスクロー ID、支払い ID、保持金額、ステータス、作成日など、資金に関するすべてがわかります。

これらのクラスはすべて、送信されるリクエストや返される応答など、システムのさまざまな部分間の通信の構(gòu)成要素を定義します。全員 (そしてすべて) が同じ認(rèn)識(shí)を持っていることを保証します。

// Domain Models
@Getter @Setter
@Entity
public class Package {
    @Id
    private String id;
    private String name;
    private BigDecimal price;
    private BigDecimal providerCost;
    private String description;
    private boolean active;
}

@Getter @Setter
@Entity
public class Order {
    @Id
    private String id;
    private String customerId;
    private String packageId;
    private String reservationId;
    private String paymentId;
    private String escrowId;
    private OrderStatus status;
    private BigDecimal amount;
    private BigDecimal providerCost;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
}

@Getter @Setter
@Entity
public class QuotaReservation {
    @Id
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

// Enums
public enum OrderStatus {
    CREATED, RESERVED, PAYMENT_PENDING, PAYMENT_COMPLETED, 
    IN_ESCROW, ACTIVATING, ACTIVATION_FAILED, COMPLETED, REFUNDED
}

public enum ReservationStatus {
    ACTIVE, EXPIRED, USED, CANCELLED
}

キャッシュサービス

1. 目的:

このサービスは、パッケージ データを保存するローカル キャッシュを処理します。目標(biāo)は、システムを高速化し、プロバイダーの API への不必要な呼び出しを減らすことです。

2. 主な特徴:

• updateCache(): このメソッドは、プロバイダーからすべてのパッケージ データをフェッチすることにより、5 分ごとにローカル キャッシュを更新します。これにより、キャッシュが最新の狀態(tài)に保たれます。
• getPackage(): このメソッドは、ID を使用してキャッシュからパッケージ情報(bào)を取得します。
• updatePackageQuota(): クォータの詳細(xì)が変更されると、このメソッドは特定のパッケージの新しい情報(bào)でキャッシュを更新します。

プロバイダーの統(tǒng)合

1. 目的:

このサービスは、プロバイダーの API との通信を処理します。クォータの確認(rèn)、パッケージの予約、サービスのアクティブ化、それらのアクティブ化の検証などのタスクを管理します。

2. 主な特徴:

• checkQuota(): このメソッドは、プロバイダーの API を呼び出して、パッケージに使用可能な十分なクォータがあるかどうかを確認(rèn)します。
• reserveQuota(): プロバイダーにリクエストを送信することで、顧客用のパッケージのクォータを予約します。
• activateService(): 注文のサービスをアクティブ化するとき、このメソッドはプロバイダーへのリクエストを処理します。
• verifyActivation(): アクティブ化後、このメソッドはすべてが成功したかどうかを確認(rèn)します。
• getAllPackages(): このメソッドは、プロバイダーから利用可能なすべてのパッケージを取得します。これは、キャッシュを更新したり、ユーザーにパッケージ オプションを表示したりするのに役立ちます。

3. 再試行メカニズム:

このサービスは、一時(shí)的な問(wèn)題が発生した場(chǎng)合に、RetryTemplate を使用してプロバイダーの API へのリクエストを自動(dòng)的に再試行します。これにより、軽微な問(wèn)題が発生した場(chǎng)合でも、システムの信頼性と復(fù)元力が確保されます。

これらの機(jī)能を組み合わせることで、このコードは、システムがプロバイダーの API とのスムーズで信頼性の高い通信を維持しながら、パッケージ データを効率的に管理できるようにします。

// Domain Models
@Getter @Setter
@Entity
public class Package {
    @Id
    private String id;
    private String name;
    private BigDecimal price;
    private BigDecimal providerCost;
    private String description;
    private boolean active;
}

@Getter @Setter
@Entity
public class Order {
    @Id
    private String id;
    private String customerId;
    private String packageId;
    private String reservationId;
    private String paymentId;
    private String escrowId;
    private OrderStatus status;
    private BigDecimal amount;
    private BigDecimal providerCost;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
}

@Getter @Setter
@Entity
public class QuotaReservation {
    @Id
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

// Enums
public enum OrderStatus {
    CREATED, RESERVED, PAYMENT_PENDING, PAYMENT_COMPLETED, 
    IN_ESCROW, ACTIVATING, ACTIVATION_FAILED, COMPLETED, REFUNDED
}

public enum ReservationStatus {
    ACTIVE, EXPIRED, USED, CANCELLED
}

ペイメントゲートウェイの統(tǒng)合

このクラスは、システムが支払いゲートウェイとやり取りして金融取引をスムーズかつ安全に処理する方法を管理する上で重要な役割を果たします。

1.initializePayment(PaymentRequestリクエスト):

• これは支払いプロセスの開始であると考えてください。すべての支払い詳細(xì)を含むリクエストを支払いゲートウェイに送信します。
• 支払い URL やセッション ステータスなどの情報(bào)を含む PaymentSession オブジェクトを返します。

2.holdInEscrow(文字列支払いID):

• この方法では、指定された支払い ID を使用してエスクロー アカウントでの支払いが保護(hù)されます。
• エスクローされた資金に関するすべての詳細(xì)を含む EscrowResponse オブジェクトを提供します。

3. releaseToProvider(String escrowId):

• サービスが正常にアクティブ化された後、このメソッドは資金をエスクローからサービスプロバイダーに解放します。
• エスクロー ID は、正しい資金を識(shí)別して解放するために使用されます。

4.返金ToCustomer(文字列エスクローID):

• サービスのアクティブ化が失敗するなど、何か問(wèn)題が発生した場(chǎng)合、この方法ではエスクローされた資金が顧客に返金されます。
• エスクロー ID を使用して返金を処理します。

主な特徴:

• このクラスは WebClient を使用して HTTP リクエストを支払いゲートウェイの REST API に送信し、シームレスな統(tǒng)合を保証します。
• 支払いの開始、エスクローの管理、返金の処理などの重要な操作を処理します。
• すべてのメソッドは同期呼び出し (.block() 経由) を使用して、次に進(jìn)む前に操作が完了していることを確認(rèn)し、信頼性を確保します。

このクラスは、システム內(nèi)で安全かつ効率的な金融取引を管理する上で、パズルの重要なピースです。

// Domain Models
@Getter @Setter
@Entity
public class Package {
    @Id
    private String id;
    private String name;
    private BigDecimal price;
    private BigDecimal providerCost;
    private String description;
    private boolean active;
}

@Getter @Setter
@Entity
public class Order {
    @Id
    private String id;
    private String customerId;
    private String packageId;
    private String reservationId;
    private String paymentId;
    private String escrowId;
    private OrderStatus status;
    private BigDecimal amount;
    private BigDecimal providerCost;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
}

@Getter @Setter
@Entity
public class QuotaReservation {
    @Id
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

// Enums
public enum OrderStatus {
    CREATED, RESERVED, PAYMENT_PENDING, PAYMENT_COMPLETED, 
    IN_ESCROW, ACTIVATING, ACTIVATION_FAILED, COMPLETED, REFUNDED
}

public enum ReservationStatus {
    ACTIVE, EXPIRED, USED, CANCELLED
}

通知 DTO

1.電子メール通知:

• これは、電子メール通知を送信するための青寫真と考えてください。これには次のものが含まれます。
  • 受信者の電子メール (宛先)。
  • メールの件名。
  • 形式を決定するテンプレート ID。
  • コンテンツをパーソナライズするための動(dòng)的データ (templateData)。

2.SMS通知:

• 電子メール通知に似ていますが、SMS 用に調(diào)整されています。これには次のものが含まれます。
  • 受信者の電話番號(hào) (phoneNumber)。
  • メッセージ形式のテンプレート ID。
  • パーソナライズ用の動(dòng)的データ (templateData)。

通知サービス

このサービスは、注文ステータスに関してユーザーに送信されるすべての通知を処理します。仕組みは次のとおりです:

1.sendSuccessNotification(注文注文):

• このメソッドは成功通知の送信を処理します。それは以下を使用します:
  • buildSuccessEmail を使用して電子メール通知を作成します。
  • buildSuccessSms を使用して SMS 通知を作成します。
  • QuotaWebSocketHandler を使用して、WebSocket 経由でリアルタイム更新も送信します。

2.sendFailureNotification(注文順序):

• これは失敗通知を処理します。それは以下を使用します:
  • 電子メール メッセージの場(chǎng)合は buildFailureEmail。
  • SMS メッセージの buildFailureSms。
  • 成功通知と同様に、WebSocket の更新も送信します。

3. ヘルパーメソッド:

• buildSuccessEmail および buildFailureEmail: これらのメソッドは、注文が成功したか失敗したかに基づいて電子メール通知を作成します。テンプレートと注文の詳細(xì)を使用します。
• buildSuccessSms と buildFailureSms: これらは同じことを行いますが、SMS 通知が対象です。

追加機(jī)能:

• WebSocket 更新: QuotaWebSocketHandler を使用して、フロントエンドをリアルタイムで更新し続けます。
• エラー ログ: 何か問(wèn)題が発生した場(chǎng)合、デバッグのためにエラーをログに記録します。

このサービスにより、ユーザーは電子メール、SMS、またはリアルタイム更新のいずれを通じてでも、注文に関する情報(bào)を常に把握できるようになります。

// Domain Models
@Getter @Setter
@Entity
public class Package {
    @Id
    private String id;
    private String name;
    private BigDecimal price;
    private BigDecimal providerCost;
    private String description;
    private boolean active;
}

@Getter @Setter
@Entity
public class Order {
    @Id
    private String id;
    private String customerId;
    private String packageId;
    private String reservationId;
    private String paymentId;
    private String escrowId;
    private OrderStatus status;
    private BigDecimal amount;
    private BigDecimal providerCost;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
}

@Getter @Setter
@Entity
public class QuotaReservation {
    @Id
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

// Enums
public enum OrderStatus {
    CREATED, RESERVED, PAYMENT_PENDING, PAYMENT_COMPLETED, 
    IN_ESCROW, ACTIVATING, ACTIVATION_FAILED, COMPLETED, REFUNDED
}

public enum ReservationStatus {
    ACTIVE, EXPIRED, USED, CANCELLED
}

QuotaUpdate クラス

• このクラスは、クォータ更新のための単純なメッセンジャーと考えてください。これには 3 つの重要な情報(bào)が含まれています。
  • packageId: 更新されるパッケージの ID。
  • availableQuota: このパッケージに殘っている割り當(dāng)て量。
  • タイムスタンプ: 更新が行われたとき。

WebSocketの設(shè)定

1.WebSocketConfig:

• WebSocket通信を可能にする設(shè)定です。
• /ws/quota で WebSocket 接続をリッスンするハンドラー (quotaWebSocketHandler) を登録します。
• また、allowedOrigins("*") を設(shè)定することで、任意のオリジンからの接続を許可します。

2.quotaWebSocketHandler():

• これは、受信メッセージと接続を管理する WebSocket ハンドラー Bean を定義します。

クォータWebSocketHandler

ここで WebSocket の魔法がすべて起こります。サーバーとクライアント間のリアルタイムの更新を管理します。

1. フィールド:

• PackageCacheService: クォータの更新が入るたびにローカル キャッシュを更新するのに役立ちます。
• ObjectMapper: JSON ペイロードから Java オブジェクトへの変換、またはその逆の変換を処理します。
• セッション: すべてのアクティブな WebSocket セッション (現(xiàn)在接続しているクライアント) を追跡します。

2. 方法:

• 接続確立後(WebSocketSessionセッション):
  • 接続するとすぐに新しいクライアント セッションをアクティブ リストに追加します。
• afterConnectionClosed(WebSocketSession セッション、CloseStatus ステータス):
  • 切斷時(shí)にクライアント セッションを削除します。
• handleTextMessage(WebSocketSession セッション、TextMessage メッセージ):
  • 受信メッセージを処理します。
  • 受信した JSON を QuotaUpdate オブジェクトに変換し、ローカル キャッシュを更新します。

3. sendOrderUpdate(注文注文):

• 接続されているすべてのクライアントに注文変更に関するリアルタイムの更新情報(bào)を送信します。
• Order オブジェクトを JSON に変換し、アクティブな WebSocket セッションにメッセージとして送信します。
• 開いている接続のみが更新を受信するようにします。

コードの主な特徴:

• リアルタイム更新:
  • クォータの変更や注文の更新についてクライアントに即座に通知します。
• スレッドセーフな管理:
  • ConcurrentHashSet を使用して接続されたクライアントを処理し、複數(shù)のクライアントがアクティブな場(chǎng)合でも競(jìng)合が発生しないようにします。
• エラー処理:
  • メッセージの送信時(shí)に問(wèn)題が発生した場(chǎng)合にエラーをログに記録するため、トラブルシューティングが容易になります。

この設(shè)定により、バックエンドとフロントエンド間のスムーズかつ即時(shí)の通信が保証されるため、ユーザーはクォータの利用可能性と注文ステータスに関する最新の情報(bào)を常に入手できます。

// Domain Models
@Getter @Setter
@Entity
public class Package {
    @Id
    private String id;
    private String name;
    private BigDecimal price;
    private BigDecimal providerCost;
    private String description;
    private boolean active;
}

@Getter @Setter
@Entity
public class Order {
    @Id
    private String id;
    private String customerId;
    private String packageId;
    private String reservationId;
    private String paymentId;
    private String escrowId;
    private OrderStatus status;
    private BigDecimal amount;
    private BigDecimal providerCost;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
}

@Getter @Setter
@Entity
public class QuotaReservation {
    @Id
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

// Enums
public enum OrderStatus {
    CREATED, RESERVED, PAYMENT_PENDING, PAYMENT_COMPLETED, 
    IN_ESCROW, ACTIVATING, ACTIVATION_FAILED, COMPLETED, REFUNDED
}

public enum ReservationStatus {
    ACTIVE, EXPIRED, USED, CANCELLED
}

これらのカスタム例外クラスの內(nèi)訳と、システム內(nèi)の特定のエラー シナリオを処理するためにそれらがどのように使用されるかを次に示します。

QuotaNotAvailableException:

• この例外は、ユーザーがパッケージを購(gòu)入しようとしたが、そのパッケージの割り當(dāng)てがすでになくなっている場(chǎng)合にトリガーされます。
• 「パッケージ クォータが利用できません」という単純なデフォルト メッセージが表示されるため、開発者とユーザーの両方が問(wèn)題を明確に理解できます。

OrderNotFoundException:

• これは、提供された orderId に基づいてシステムが注文を見つけられない場(chǎng)合に開始されます。
• 「注文が見つかりません: [orderId]」などの詳細(xì)なエラー メッセージが含まれているため、どの注文が欠落しているかを正確に特定するのが簡(jiǎn)単になります。

PaymentVerificationException:

• 金額が一致しない、または支払いステータスが不明瞭であるなど、支払いの確認(rèn)に問(wèn)題がある場(chǎng)合、この例外がスローされます。
• カスタム メッセージを渡すことができ、支払いの問(wèn)題を診斷するための柔軟性とコンテキストが追加されます。

これらの例外を使用することにより、システムはクリーンかつ予測(cè)可能な方法でエラーを処理します。これらは開発者にとってデバッグの効率を高めるだけでなく、何か問(wèn)題が発生したときにユーザーが明確で実用的なフィードバックを確実に受け取ることができます。

// Request/Response DTOs
@Getter @Setter
public class OrderRequest {
    private String customerId;
    private String packageId;
    private BigDecimal amount;
}

@Getter @Setter
public class PaymentCallback {
    private String orderId;
    private String paymentId;
    private String status;
    private BigDecimal amount;
    private LocalDateTime timestamp;
}

@Getter @Setter
public class QuotaResponse {
    private String packageId;
    private boolean available;
    private Integer remainingQuota;
    private LocalDateTime timestamp;
}

@Getter @Setter
public class ReservationResponse {
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

@Getter @Setter
public class ActivationResponse {
    private String orderId;
    private boolean success;
    private String activationId;
    private String errorCode;
    private String errorMessage;
}

@Getter @Setter
public class VerificationResponse {
    private String orderId;
    private String activationId;
    private boolean success;
    private String status;
    private LocalDateTime activatedAt;
}

@Getter @Setter
public class PaymentRequest {
    private String orderId;
    private BigDecimal amount;
    private String currency;
    private String customerId;
    private String returnUrl;
    private String callbackUrl;
}

@Getter @Setter
public class PaymentSession {
    private String sessionId;
    private String paymentUrl;
    private LocalDateTime expiresAt;
    private String status;
}

@Getter @Setter
public class EscrowResponse {
    private String id;
    private String paymentId;
    private BigDecimal amount;
    private String status;
    private LocalDateTime createdAt;
}

OrderService クラスは、注文の管理に関する面倒な作業(yè)を処理します。その仕組みを詳しく見てみましょう:

主な責(zé)任

1. createOrder(OrderRequest リクエスト):

   • この方法は、新しい注文を作成することだけです。パッケージが利用可能かどうかを確認(rèn)し、詳細(xì)を取得してクォータを予約し、注文を初期ステータス RESERVED でデータベースに保存します。

2. processPayment(String orderId, PaymentCallback コールバック):

   • ここで支払いが処理されます。システムは支払いの詳細(xì)を確認(rèn)し、注文を更新し、支払いをエスクローに預(yù)け、サービスのアクティブ化プロセスを開始します。何か問(wèn)題が発生した場(chǎng)合、失敗を適切に管理します。

3. verifyActivation(注文順序):

   • このメソッドは、サービスのアクティベーションがスムーズに行われたかどうかを再確認(rèn)します。最大 3 回試行し、それでも失敗した場(chǎng)合、システムはフォールバックして失敗を処理します。

4. completeOrder(注文注文):

   • すべてがチェックアウトされると、このメソッドで注文が確定します。エスクロー資金をプロバイダーに解放し、ステータスを更新し、成功についてユーザーに通知します。

5. handleActivationFailure(注文順序):

   • アクティベーションが失敗した場(chǎng)合、この方法により顧客は返金と問(wèn)題の原因に関する通知を確実に受け取ります。

6. getOrder(String orderId):

   • この簡(jiǎn)単なメソッドは、ID によって注文を取得します。注文が存在しない場(chǎng)合は、特定の例外がスローされます。

なぜ機(jī)能するのか

• トランザクションの性質(zhì)により、トランザクションが完了するかロールバックされることが保証されます。
• 明確なエラー処理と再試行により、現(xiàn)実世界の問(wèn)題を処理するのに十分な堅(jiān)牢性を備えています。
• 通知により、ユーザーはあらゆる段階で最新情報(bào)を把握できます。

このサービスは注文管理プロセスのバックボーンであり、すべてを結(jié)び付けてシームレスなユーザー エクスペリエンスを?qū)g現(xiàn)します。

// Domain Models
@Getter @Setter
@Entity
public class Package {
    @Id
    private String id;
    private String name;
    private BigDecimal price;
    private BigDecimal providerCost;
    private String description;
    private boolean active;
}

@Getter @Setter
@Entity
public class Order {
    @Id
    private String id;
    private String customerId;
    private String packageId;
    private String reservationId;
    private String paymentId;
    private String escrowId;
    private OrderStatus status;
    private BigDecimal amount;
    private BigDecimal providerCost;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
}

@Getter @Setter
@Entity
public class QuotaReservation {
    @Id
    private String id;
    private String packageId;
    private LocalDateTime expiresAt;
    private ReservationStatus status;
}

// Enums
public enum OrderStatus {
    CREATED, RESERVED, PAYMENT_PENDING, PAYMENT_COMPLETED, 
    IN_ESCROW, ACTIVATING, ACTIVATION_FAILED, COMPLETED, REFUNDED
}

public enum ReservationStatus {
    ACTIVE, EXPIRED, USED, CANCELLED
}

OrderController クラスは、システム內(nèi)の注文を管理する REST API エンドポイントを処理します。 Think は、リクエストを行うクライアントと、面倒な作業(yè)を行うバックエンド サービスとの間の橋渡しとなります。

主要なエンドポイント

1. POST /api/orders (createOrder):

   • このエンドポイントは、新しい注文の作成を処理します。
   • 何が起こるか:
     • クライアントから OrderRequest を受け取ります。
     • OrderService.createOrder を呼び出してリクエストを処理し、注文を作成します。
     • 返信:
       • すべてがうまくいけば、新しく作成された注文に対して 200 OK の応答が返されます。
       • パッケージ クォータが使用できない場(chǎng)合の 409 競(jìng)合。
       • 予期しない問(wèn)題に対する 500 內(nèi)部サーバー エラー。

2. POST /api/orders/callback (handlePaymentCallback):

   • これは、支払いゲートウェイによって送信された支払い更新を処理します。
   • 流れは次のとおりです。
     • すべての支払い詳細(xì)を含む PaymentCallback を受け取ります。
     • OrderService.processPayment を呼び出して支払いを処理し、注文ステータスを更新します。
     • 可能な応答は次のとおりです:
       • 支払いが正常に処理されれば 200 OK。
       • 指定された注文 ID が存在しない場(chǎng)合は、404 Not Found。
       • 422 支払い検証に不一致がある場(chǎng)合は処理できないエンティティ。
       • 予期せぬ事態(tài)に対する 500 內(nèi)部サーバー エラー。

3. GET /api/orders/{orderId} (getOrder):

   • このエンドポイントは、ID によって特定の注文の詳細(xì)を取得します。
   • 仕組みは次のとおりです。
     • OrderService.getOrder を呼び出して注文を取得します。
     • 戻り値:
       • 見つかった場(chǎng)合は、注文の詳細(xì)を含む 200 OK 応答。
       • 注文 ID がどのレコードにも一致しない場(chǎng)合は、404 Not Found が返されます。

特徴

• 関心事の分離: OrderController はすべてのビジネス ロジックを OrderService に委任し、物事をクリーンかつ集中的に保ちます。
• 検証: リクエストのペイロードは @Valid アノテーションを使用して検証され、受信したデータが期待を満たしていることを確認(rèn)します。
• エラー処理:
  • 利用できない割り當(dāng)てや注文の欠落など、一般的な問(wèn)題に対して具體的で役立つ回答を提供します。
  • デバッグを容易にするために問(wèn)題をログに記録します。
• ロギング: 受信リクエスト、エラー、注文の詳細(xì)などの主要なイベントを追跡して、可視性を高めます。

このコントローラーにより、クライアントとバックエンドがシームレスに通信できるようになり、注文管理が可能な限りスムーズになります。

結(jié)論

この調(diào)査文書は、クォータ管理、支払い処理、サービスのアクティベーションなどの重要な課題に取り組む、電子商取引信用販売システムを設(shè)計(jì)するための基礎(chǔ)を示します。このデザインは基本をカバーしていますが、改善の余地は常にあります!

このデザインを改善するためのアイデアをいくつか紹介します:

• イベント駆動(dòng)型アーキテクチャを使用して、システムをより柔軟でスケーラブルにします。
• 大量のトランザクションをスムーズに処理するために、メッセージ キュー ベースの処理を追加します。
• 高度なキャッシュ戦略を検討して、処理を高速化し、外部 API への依存を軽減します。
• スケーリングを容易にし、信頼性を向上させるために、分散システム パターンを検討してください。
• サードパーティサービスの中斷を適切に処理するために、サーキットブレーカーを?qū)g裝します。
• モニタリングとアラートを設(shè)定して、問(wèn)題を早期に発見し、迅速に修正します。
• ユーザーとそのデータを保護(hù)するために、セキュリティ対策を強(qiáng)化します。

読んでいただきありがとうございます!このドキュメントが役に立ち、同様の課題を検討している人にとって明確な情報(bào)を提供できれば幸いです。もちろん、この設(shè)計(jì)は完璧ではありません。常に改善の余地があります。ご意見やご提案がございましたら、ぜひお聞かせください。

リソース:

• クリーンなアーキテクチャと堅(jiān)実な原則についての詳細(xì)
• マイクロサービス アーキテクチャを使用した電子商取引アプリケーションの設(shè)計(jì)
• フラッシュ セールス用のスケーラブルなバックエンドの設(shè)計(jì)
• ウィキペディアのエスクロー

以上がインターネットクレジット購(gòu)入システムの設(shè)計(jì)の詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國(guó)語(yǔ) Web サイトの他の関連記事を參照してください。