MongoDBでCQRS + Event Sourcingアーキテクチャを実装する新しいプロジェクトを開始します。私たちは既にCQRSのアプローチについていくつかの経験を持っています。以前のプロジェクトでは、Fohjinのフレームワークを出発点にしました（よくリファクタリングしました）。 Oracleをストレージとして使用し、その場合はTransactionScopeで2PCを実装しました。CQRS、Event Sourcing、NoSQLデータベース
しかし私たちの新しいプロジェクトでは、スケーラビリティとパフォーマンスの面でMongoDBを使いたいと考えています。私たちは間違いなくread（report）の部分に使用し、イベントストアのためにそれを補いたいと思っています。代わりに、SQL Serverを使用してイベントを格納する方法もあります。だから我々は選択をする必要があります。私がハイブリッドソリューションについて気に入らないのは、高価で遅く、異なるDbタイプ（MongoとSQL）をサポートする必要があるTransactionScopeです。
私たちはNCQRSを見ましたが、私たちは私たちの視点とは異なる方法で実装できる多くのフレームワークに強く依存したくないようです。そこで、私たちはJonathan Oliverのイベントストアのような軽量なものを考えています。私はストリームとコミットのコンセプトが好きで、MongoDBもサポートしています。私がまだ理解していないもの、それが2PCのすべてのものをどのように処理するか（NoSQLの場合）私たちの場合、いくつかのイベントハンドラにイベントをディップする必要があります。特定のタイプのイベントのために、読み込みデータベースとタスクスケジューラを更新する何らかのデノミザライザーです。これらのハンドラに何か問題があり、例外が発生した場合、MongoDBのコミットをロールバックする方法はありません。これに対処するトリックはありますか？
私は正しい判断を下す方法と賛否両論について何かコメントをいただき、ありがとうございます。
はあなたの答え、エリオットいただきありがとうございます。私が理解する限りでは、イベントハンドラ/パイプラインフックを無意味にする必要があります。イベント/コミットがすでにディスパッチされたと判断するフィルタを追加します。それは各ハンドラのために余分なコードをたくさん追加するように思えます（多分、それはアスペクトまたはこれのようなものとして実装することができます）。 Busidesでは、各ハンドラに新しいdbクエリを追加してチェックします。しかし、私たちはそれを「ソリューションのコスト」と呼ぶことができます。別の問題は、部分的に処理されるイベント/コミットを処理するときです。 – Voice
ええ、独自のイベントハンドラを冪等にするためのインフラストラクチャを構築する必要があります。あなたのイベントにユニークなIDを埋め込み、このIDを読んだモデルに含めることで、イベントを複数回処理したかどうかを知ることができます。 –