問題タブ [cqrs]

CQRSスタイルのパターン（イベントソーシングなし）を使用しています。読み取りと書き込みを2つの別々のアプリケーション境界に分離するだけです。

現在、アプリケーションは1つのSQL2008データベースに対して機能します。ボリュームが大きくなり始めているので、ワークロードを分散するために複数の読み取りデータベースを追加したいと思います。

単一のデータベースを更新し、変更をリアルタイムで他のノードに複製/伝播できるSQL2008のソリューションが必要です。アプリケーションは単一の「マスター」データベースにのみ書き込むため、これは一方向の伝播である必要があります。

ピアツーピアのトランザクションレプリケーションについて読みました。それを使用したことがある人は、子ノードの更新にどのくらいの待ち時間がありますか？

他の解決策はありますか？

CQRS (Command and Query Responsibility Segregation) アプローチは、堅牢で応答性の高いソーシャル アプリケーション サーバーを GAE に実装するのに適しているように思えます。その理由は次のとおりです。

1. CQRS は SQL データベースを必要としません (GAE は提供しません)。
2. シリアル化されたオブジェクトを保持できるデータベースが必要ですが、GAE が実際に提供しています。
3. GAEも提供するイベントキューが必要です
4. ノンブロッキング、非同期、メッセージベースのアーキテクチャをサポートしており、長時間実行されるトランザクションに対する GAE の制限をうまく回避します。
5. スケーラビリティが高いと宣伝されているため、楽観主義者が GAE を選択するのはこれが理由です。

問題は、私はこの選択に関連する経験がほとんどない錆びた Java プログラマーであり、2 つを一緒に使用したことのある人、または少なくとも一方を使用した経験から他方を使用して調査したことのある人からのコメントを非常に歓迎することです。

私の主な質問は次のとおりだと思います。

1. 新しいアプリケーションの初期段階で CQRS は複雑すぎますか?
2. GAE のデータストアが CQRS の要件にうまく適合しないなど、適合性が低くなるブービー トラップはありますか?
3. AxonまたはJdonのいずれかが GAE に特に適している (または適していない) と推奨できる人はいますか?
4. 他にどのような質問をする必要がありますか?

J OliverのEventStoreとmongoを永続層として使用する新しいプロジェクトのイベントソーシングを検討してきましたが、いくつかの質問に遭遇しました。

1. イベントソーシングを試す前は、ドメインはデータベースに永続化され、 NHibernateが作業単位を管理することで非常にうまく機能したUdiのドメインイベントパターンを使用していました。しかし、私は複数の集合体に影響を与える可能性のある1つの作業単位になってしまいました。

   ハンドラーが応答するイベントを発生させるショッピングバスケットアグリゲートを「チェックアウト」し、請求書アグリゲートを作成してイベントを発生させます（これは単なる例です）。

   この場合、2つの集約ルートを変更する1つの作業単位があります-イベントストアで、発生したイベントを2つの異なるイベントストリームに追加できますが、それらはアトミックな方法で永続化されません（最初は成功し、2番目は失敗する可能性があります） 。では、これを回避するために人々は何をしますか？

2. githubのホームページでは、流暢なインターフェイスを使用してEventStoreを構成できることが示されていますが、ソースをダウンロードしてコンパイルし、例を見ると、ワイヤーアップクラスが利用できないようです-別のブランチにありますか？ ？（私にはマスターがいます）

3. IStoreEvents implを処理するための推奨される方法は何ですか？Nhibernatesセッションファクトリに似たシングルトンとして？

NEventStore を使用する場合、どのように NServiceBus に統合しますか?

私はNSB ans ESを初めて使用し、ESとCQRSを使用する場合のNSBの最適なセットアップを見つけようとしています。

例の DispatchCommit と同じ方法で NSB に接続してい ます。 https://github.com/joliver/EventStore/blob/master/doc/EventStore.Example/MainProgram.cs

1. Commit または Commit.Events 全体を公開しますか?
2. NSB はメッセージに IMessage を必要とするため、メッセージの周りにラッパーを作成しますか? では、正しいキューにどのように公開しますか? たとえば、 OrderSubmittedEvent とは対照的に、ラッパーは汎用であるためです。可能であれば、イベントの NSB への依存を望んでいません。これは、ドメインにもそれがあるためです。

いくつかのコードまたはガイダンスは本当に感謝しています。

現在、CQRSとイベントソーシングアーキテクチャを評価しています。この種の設計を使用することのメンテナンスへの影響が何であるかを理解しようとしています。私が答えを見つけるのに苦労している2つの質問はこれです：

1）アプリケーションが起動してしばらく実行された後、ReadModelデータベースのViewModelにフィールドを追加する新しい要件がある場合はどうなりますか？たとえば、CustomerList ViewModelには顧客の郵便番号が必要ですが、以前は必要ありませんでした。したがって、追加の列はViewModelデータベースに簡単に追加できますが、これはどのように入力されますか？私が見る限り、唯一の方法は、読み取りデータベースをクリアし、すべてのイベントを最初から再生して、ReadModelDatbaseを構築することです。しかし、アプリケーションが数か月または数年にわたって稼働している場合はどうなりますか（私たちが望むように）。これは、郵便番号列のデータを追加するためだけに、何百万ものイベントを再生する可能性があります。

技術的な理由でReadModelデータベースが同期しなくなった場合、または新しいReadModelデータベースを追加したい場合も、同じ懸念があります。アプリケーションが古く、使用するほど、最新のreadmodelを元に戻すのは難しく、費用もかかるようです。それとも私はどこかでトリックを逃していますか？ReadModelスナップショットのようなものですか？

2）読み取​​りデータベースをバックアップするために何百万ものイベントがすべて再生された後、一部のデータが期待されたものと一致しない場合（つまり、見た目が間違っている場合）はどうなりますか。おそらく、イベントの保存または非正規化ルーチンのどこかにバグが原因である可能性があります（コーディングで信頼できることが1つあるとすれば、それはバグのようです）。これをデバッグする方法！それは不可能な仕事のようです。または多分、もう一度、私はトリックを逃しています。

このようなシステムをしばらく実行している人から、メンテナンスとアップグレードのパスがどのように機能したかを聞いてみたいと思います。

いつでもご入力いただきありがとうございます。

CQRS は非常に理にかなっています。ただし、変更追跡を提供する ORM を使用するアプローチとは相容れないようです。オブジェクトを RO として取得するためのクエリ用の「チャネル」が 1 つある場合、追跡する変更はありません。CUD+ コマンド用の別のチャネルがある場合、軽い DTO を使用した RPC アプローチのほうが多く、自己追跡エンティティを送信して下位層でマージします。

これら 2 つのアプローチ (CQRS / ORM + STE) をどのように調和させることができますか?

独自のサービス バスでビルドするにはどうすればよいですか? NService バス、Rhino バスなど、利用可能なオープン ソース サービス バスがたくさんあることは知っていますが、実際にやってみたいと思います。

1) バスをどのように構築しますか? その特徴とは

2) Queue テクノロジから独立させるにはどうすればよいですか..つまり、Azure キューとして MSMQ で動作するはずです (Azure キューで動作したことはありません)。

3)リスナーを実装するにはどうすればよいですか? リンクを取得しました..それはNservice Busが行った方法です （MSMQListner）

4) キューをアクティブ化するにはどうすればよいですか .. IIS でサービスをホストして、負荷の処理が問題にならないようにすることはできますか (そう願っています)。

5) MSMQ のホスト オプションはどのようになりますか?

私はWCFを使いたくありません。それは、メッセージングアーキテクチャをRPC呼び出しとして作成するからです

私は2つのシナリオを見ていました：Aは大丈夫です、Bはわかりません。

シナリオA：コミット後、ディスパッチ前にアプリケーションの再起動をシミュレートする

1. EventStoreを開始します
2. 変更をコミットする
3. イベントはディスパッチされません
4. イベントストアを停止する
5. イベントストアを開始

コミットされたイベントは、手順5で再度送信されます。これは正常に機能し、ディスパッチャコードでも確認できます。

シナリオB：バスエラーをシミュレートする

1. EventStoreを開始します
2. 変更をコミットする1
3. ディスパッチャの例外
4. 変更をコミットする2
5. 発送OK

この場合、動作を見つけることができず、それが有効なケースであるかどうかも疑問に思います。これは、バスコードにバグがあった場合にのみ発生する可能性があります。

ディスパッチを再試行するトリガーはありますか、それともこれを処理するためのコードを記述する必要がありますか、それとも私の推論に誤りがありますか？

新しいプロジェクトで CQRS と EventSorcing を使用しようとしています。私は、Greg Young が数年前に提案した方法に従っています (Mark Nijhof の実装 - http://cre8ivethought.com/blog/2009/11/12/cqrs--la-greg-young/ )。また、このソリューションのスケーラビリティに関していくつかの問題があります。

この中でいくつかの点が言及されたマーク・ナイホフの記事。しかし、現在の問題は、レポート データベースの更新を担当する Denormalizer 部分です。この部分は非同期にしたいので、バスにイベントを発行したらすぐに制御を戻したいです。Denormalizer をスタンドアロンの Web サービス (WCF) として実装し、受信イベントを処理し、コマンドのバッチでタイミングを合わせてレポート データベースを更新することを提案しました。これがボトルネックになる可能性があるため、この時点である程度のスケーラビリティも追加したいと考えています - クラスタ ソリューションです。しかし、クラスターの場合、レポート データベースの更新のシーケンスを制御することはできません (または、レポート DB でオブジェクトのバージョンをチェックする、いくつかの奇妙でバグのあるロジックを実装する必要があります)。もう 1 つの問題は、ソリューションの持続可能性です。失敗した場合、どこにも永続化しない限り、デノーマライザーで更新が失われます)。だから今、私はこの問題（デノーマライザーのスケーラビリティ）の解決策を探しています。どんな考えでも大歓迎です！