MongoDB で CQRS + イベント ソーシング アーキテクチャを実装する新しいプロジェクトを開始しています。すでに CQRS アプローチの経験があります。以前のプロジェクトでは、Fohjin フレームワークを出発点として採用しました (まあ、大幅にリファクタリングしました)。Oracle をストレージとして使用し、その場合は TransactionScope で 2PC も実装しました。
しかし、新しいプロジェクトでは、スケーラビリティとパフォーマンスのために MongoDB を使用したいと考えています。読み取り（レポート）部分に使用し、イベント ストア用に検討したいと考えています。ここでの代替手段は、イベント ストレージに SQL Server を使用することです。だから私たちは選択をする必要があります。ハイブリッド ソリューションについて私が気に入らないのは、高価で遅く、異なる Db タイプ (Mongo と SQL) をサポートする必要がある TransactionScope です。
私たちは NCQRS を調べましたが、どのフレームワークにも大きく依存したくないようです。フレームワークは、私たちの観点からはさまざまに実装できる多くのことを指示します。そこで今、Jonathan Oliver の Event Store のようなもっと軽量なものを考えています。ストリームとコミットの概念が好きで、MongoDB もサポートしています。私がまだ理解していないこと、それが2PCのものすべてをどのように処理するか（NoSQLの場合と述べられています）。私たちの場合、イベントをいくつかのイベント ハンドラーにディスパッチする必要があります。読み取りデータベースを更新するある種のデノマライザーと、特定の種類のイベントのタスク シェデュラーです。これらのハンドラーに問題が発生して例外が発生した場合、MongoDB のコミットをロールバックする方法はありません。これを処理するためのトリックはありますか？
正しい決定を下す方法と、長所と短所についてコメントをいただければ幸いです。