1つのアプリケーションで複数のプラグ可能な支払いシステムのアーキテクチャの考え方

Question

私たちは1年前から電子商取引アプリケーションを開発しており、さまざまな国でビジネスを始めました。これは、単一のアプリケーション内に多数の非常に異なる支払いシステムを実装する必要があることを意味します。たとえば、各国ごとに異なるタイプのクレジットカードプロセッサゲートウェイ、一部の国のモバイル決済ゲートウェイ、ペイパル、各国の直接銀行など...これらのシステムはそれぞれ独自のデータで独自に設計されていますモデル、時には独自のワークフローを使用しており、異なる国でこれらの支払いシステムの異なるサブグループを使用しています。これはプラグイン可能にする必要があります。しかし、私たちはそのようなアーキテクチャに関する経験はありません。必要に応じて1つずつ追加することから始めたので、データベースには1つのテーブルしかなく、この単一のテーブルにはサポートしているすべての支払いシステムのすべてのフィールドが含まれているため、現在のところ実際のアーキテクチャはありません。エラーが発生しやすく、混乱します。

それぞれ独自のデータモデルを持つが、プラグイン可能なこれらのさまざまな支払いオプションのすべてに対して、真にプラグ可能なシステムを作成する最良のソリューションとは何でしょうか？

Answer 1

これに共通するアプローチは、支払い機能を別々のモジュールにバンドルすることです。支払取引が成功するかどう探るために、すなわち、限られた時間のための信用を確保するために

• reserve()：モジュールは、ビジネス・ロジックに向けた、2つの主な方法を公開します。
• commit()は、以前予約された実際のマネーフローをトリガーします。

ビジネスロジックがに-支払われる活動

を実行する前に

1. reserve()支払いが活動を行う（例えばコンテンツを配信する、...）でしょう
2. commit()支払い

ほとんどの支払いシステムは、このスキームに適合している必要があります。

これに加えて、ユーザー情報に基づいて正しい支払いモジュールに送信するためのプラグインメカニズムが必要です。