アーキテクチャモデル：イベント駆動型モード

問題

あなたは、すべてのサービスアプリケーションデータベースのスキーマを持っています。各サービスは、独自のデータベースを持っています。ただし、サービス間のデータの一貫性を確保するためのメカニズムを必要とするので、複数のサービスにまたがるいくつかのビジネストランザクション。

たとえば、あなたが顧客を構築していると仮定し、eコマースストアのクレジットラインを持っています。アプリケーションは、新しい注文が顧客の与信限度を超えていないことを確認する必要があります。以来注文と顧客が異なるデータベースに配置されているため、アプリケーションは、単にローカルACIDトランザクションを使用することはできません。理論的には、顧客サービスと注文サービス間で分散トランザクションを使用することができます。しかし、様々な理由のために、分散トランザクションは、最も近代的なアプリケーションのための実行可能な選択肢ではありません、。

ソリューション

イベント駆動型、そして最終的に一貫したアプローチ。そのデータを更新する際に各サービスは、イベントをパブリッシュします。その他のサービス加入活動。イベントを受信した後、サービスは、そのデータを更新します。

結果のコンテキスト

このモデルは、次の利点があります。

これは、分散トランザクションを使用せずに、複数のサービス間でのデータの一貫性を維持するために、アプリケーションを可能に

このソリューションは、以下の欠点があります。

より複雑なプログラミングモデル

以下の課題があります。

確実に、アプリケーションはアトミックにそのデータベースを更新し、イベントを発行しなければならないために。これは、データベースや報道機関に分散トランザクション間の伝統的なメカニズムを使用することはできません。代わりに、それは、下記のモードのいずれかを使用する必要があります。

例

次のように電子商取引アプリケーションのこの方法を使用することで動作します。

オーダサービスは保留状態に順序を作成し、OrderCreatedイベントを公開します。
カスタマーサービス部門は、イベントを受信して、その順序のための信用を維持しようとします。その後、クレジット予約CreditLimitExceededイベントまたはイベントを公開します。
注文サービスが承認としてキャンセルされた顧客サービス部門からイベントを受信し、注文状況を変更したり、