バックグラウンド
メッセージ キュー ドメインがあります。このドメインは、一部のメッセージ キュー テクノロジで動作する場合があります。この特定のケースでは、Windows Azure Service Busにバインドされています。
一部のプロジェクトには、 Windows Azure Service Busトピック (基本的にはメッセージ キュー)を登録する操作があります。
新しいメッセージ キューの登録とは、次のことを意味します。
- ドメイン トランザクション (つまり、データベース トランザクション) を開始します。
- メッセージ キュー ドメイン オブジェクトをいくつかの関連情報と共に追加します (どのユーザーがそれを登録したか、どのアプリケーションにメッセージ キュー全体が属しているかなど)。
- 制御の反転を使用して、メッセージ キュー サーバーで実際のキュー登録を処理します (この場合、Windows Azure Service Bus に対して発生します)。
- 何も問題がなければ、ドメイン トランザクションがコミットされ、関連するドメイン オブジェクトが永続化または更新されます。
上記の背景では、ドメイン トランザクションが正常に終了し、Windows Azure Service Busのトピック登録が正常に機能していれば、正常に機能するはずです。
問題
しかし、ドメイン トランザクションが正常に終了しても、Windows Azure Service Busがトピック (別名メッセージ キュー) を登録できなかった場合はどうなるでしょうか?
はい、ドメインが壊れています。
また、ドメインのトランザクションが開始される前に、 Windows Azure Service Busのトピック登録を行うとどうなりますか? まあ、うまく行けば問題ない。しかし、今度は問題が逆転しました。Windows Azure Service Busトピックが正しく登録された後、ドメイン トランザクションが失敗した場合はどうなるでしょうか?
そうです、この 2 番目のケースは、最初に説明したケースよりも優れています。これは、操作によって役に立たないメッセージ キューが登録されましたが、ドメインはそれを認識しないためです。現在の主な問題は、不確定な数のトランザクションが失敗する可能性があり、不明な数のメッセージ キューが無意味に存在することです。
これが深刻で大規模なビジネス サービスであるかどうか想像してみてください。大量の無用なメッセージ キューと、システム管理者 (人間) が無用なメッセージ キューを毎月削除している.
それで何 - 今質問 - ？
ドメインが壊れるよりも、役に立たないメッセージ キューを使用する方がよいと判断したため、この方法で進めることにしましたが、リモート オブジェクトを含めるために、Windows Azure にはあらゆる種類の分散トランザクション メカニズムがあります。他のドメイン固有の操作を含むアトミック トランザクションでの作成? 、そうでない場合-悲しいことに、これが実際の状況であると思います-、このシナリオをどのように解決しますか?
ノート：
ユースケースをまったく処理できないドメインを持つのは本当に好きではないので、私はこのようなものを探しています. 私はこれを避けて、ドメインが適切に機能し、すべてを制御できるようにすることを好みます。
いくつかの興味深いリンク...
このトピックに関する興味深いリンクを見つけました。