問題タブ [cqrs]

EventStore と CommonDomain を使用するときに集約のスナップショットを作成するためのベスト プラクティスと考えられるものは何ですか?

イベント ソーシングに関する有用なディスカッション グループ、記事、サクセス ストーリー、リファレンス アプリ、およびツール (.Net) に関する提案を探しています。

私はすでによく知っています：

ファウラーの記事: http://martinfowler.com/eaaDev/EventSourcing.html

Greg Young の記事 (コメントにダウンロードしたドキュメントを含む): http://codebetter.com/gregyoung/2010/02/20/why-use-event-sourcing/

Greg Young の DDDD に関する優れた (ドラフト) 記事: http://abdullin.com/storage/uploads/2010/04/2010-04-16_DDDD_Drafts_by_Greg_Young.pdf

他に読んで見るべきものはありますか？

現在、 Azureでホストされるプロジェクトに使用するCQRSフレームワークを検討しています。

Ncqrsと Lokad.CQRSについて読んだことがありますが、現在少し混乱しています。

どちらも Azure で動作しますか、どちらも NServiceBus を使用できますか、それとも Lokad は独自のメッセージングを使用しますか?

私が使用するクライアントは、Web とモバイルの両方です。コマンドを取得するための WCF サービスを作成することを考えましたが、それが WCF になるかどうかはわかりません。

推奨事項はありますか？

リポジトリ クラスの「GetById」メソッドからロードされるモデル クラスがあります。このエンティティに追加のプロパティを追加する必要があります。これらはデータベースには保存されませんが、サービス クラスによって計算されます。何かのようなもの：

したがって、MyEntity オブジェクトをロード/サチュレートするには、データベースからロードし、ジェネレーターを呼び出して「ウー ファクター」(エヘム) を決定する必要があります。アーキテクチャの観点から、このコードはどこに行くべきですか? 現在の考え:

1) リポジトリ内: ここに追加すると、リポジトリに責任を押し付けすぎているように感じます。

2) 「MyEntity」クラス。アクセス時に WooFactor を遅延ロードするコードをここに追加します。これにより、MyEntity に多くの依存関係が追加されます。

3) 別のサービス クラス - やり過ぎで不必要に思えます。

EventStore に保存されているすべてのイベントにアクセスして、読み取りモデルを再構築するにはどうすればよいですか?

呼び出されるメソッドGetFromは質問J Oliver EventStore V2.0 の質問に記載されていますが、Wireup から返されるインターフェイス "IStoreEvents" でこのメソッドが見つかりません。

私はまだ DDD の初心者であり、CQRS の初心者であることは認めます。また、DDD や CQRS がすべての問題に対する適切なアプローチではない可能性があることも認識しています。それにもかかわらず、私はプリンシパルが好きですが、現在のプロジェクトのコンテキストでいくつか質問があります.

ソリューションは、現在の構成に基づいてパフォーマンス データを生成するシミュレータです。管理者は、シミュレーションの仕様を作成および変更できます。テスターはいくつかの環境条件を設定し、シミュレーターを実行します。結果がキャプチャされ、集計され、レポートされます。

このソリューションは、それぞれ独自のユース ケース、ドメイン ロジック、およびサポート データ構造を持つ 3 つのコンポーネント領域で構成されます。その結果、モジュラー設計は、ロジックを分離し、関心を分離する方法として魅力的に見えます。

1. 最初の領域は、ユーザーが仕様を作成および変更できるようにする管理面です。これは、CRUD を多用する「モジュール」になります。
2. 2 番目の領域は、シミュレーションを実行するためのものです。ドメイン モデルは最初の領域に似ていますが、編集に便利なモデルを提供するのではなく、シミュレーションを実行するために最適化されています。
3. 3 番目の領域はレポートです。

このことから、私は 3 つのバウンディング コンテキストを持っていると信じています。アプリケーションへの 3 つの明確なエントリ ポイント、3 つのドメイン ロジック セット、およびドメイン ロジックをサポートする 3 つの異なるデータ モデルがあります。

私の最初の本能は、これらの方針に従い、各領域のドメイン層をカプセル化する 3 つのモジュール (アセンブリ) を作成することです。また、3 つの別個のデータベースを使用する必要がありますか? 書き込みと読み取りをサポートするために 3 つ以上でしょうか?

これはCQRSに適しているかもしれませんが、どうすればよいかわかりません。CQRS は、データを移動する一連のバックエンド プロセスを提案しているように思えます。しかし、それが事実であり、データの永続性が (DDD が示唆するように) 横断的である場合、データ アクセス コードはすべてのドメイン オブジェクトを認識する必要があるのではないでしょうか? もしそうなら、別々のモジュールを持つことには利点がありますか?

最後に、先ほど言い忘れたことは、仕様は発行されるまでは「ドラフト」と見なされ、その後シミュレーションに使用できるようになるということです。私の PublishingService は、SpecificationPublishedEvent に応答するときに、仕様を読み取り、モデルを変換し、実行のために永続化できるように、最初と 2 番目の領域の両方のドメイン モデルの知識を持っている必要があります。これは、結局のところ、3 つの境界コンテキストがないと思わせてくれます。それとも、私の分析で何かが欠けていますか?

CQRS の「作業単位」をどのように解決しますか? 「タイトル」と「説明」を更新するコマンドが必要ですが、「リンク」は更新しません..

someclass {文字列のタイトル; 文字列 説明。文字列[] リンク; }

JOliverのEventStoreライブラリを評価しています。特に、EventStoreの永続化エンジンとしてRavenDBを使用しようとしています。EventStoreにはこのためのプラグインが付属しています。注：データベースは空で、インデックスはありません（デフォルト以外）。

店舗の配線には、以下を使用しました。

ただし、プログラムを実行すると、「RavenCommitByRevisionRange」インデックスが見つからなかったことを示す例外が発生します。

EventStoreコードを掘り下げると、RavenPersistenceEngineが初期化されていないことが問題だと思います。初期化コードは、必要なインデックスをRavenDBサーバーにインストールします。

SQLサーバー側では、サンプルプロジェクトの配線コードに、「InitializeStorageEngine」という拡張メソッドの呼び出しが示されていることに気付きました。この拡張メソッドは、クラス「PersistenceWireup」に関連付けられています。ただし、RavenDB永続性をワイヤリングするために使用している拡張メソッドは、クラス「Wireup」を返します。そこで、ワイヤーアップコードの一部を新しいPersistenceWireupインスタンスにラップし、次のように「.InitializeStorageEngine（）」を呼び出すことができました。

これはうまくいきます！これで、RavenDBデータベースに必要なインデックスが含まれるようになりました。

だから...私の質問：「。UsingRavenPersistence（...）」は単に「Wireup」ではなく「PersistenceWireup」のインスタンスを返すべきではありませんか？または、EventStoreでRavenDBの永続性を接続するためのより良い方法はありますか？

私のCQRSアーキテクチャでは、InsertSettingCommand（設定はキー/値オブジェクト）を送信するときに、キーがデータベースにまだ存在しないことを確認したいことを検証したいと思います。CQRSと検証をよく理解している場合、検証は、電子メールが構文を尊重していることや顧客の名前が空でないことを確認するなど、フォーマットに関するものを検証する場合にのみ、クライアント側で実行する必要があると言われています。しかし、私の場合、データベースにクエリを実行してデータベースが存在するかどうかを確認する必要がありますが、クライアント側の読み取りストアにクエリを実行するのが正しいかどうかわかりません。または、ドメイン側の読み取りストアに電話する必要がありますか？次に、InsertSettingDuplicatedイベントをスローしますか？

では、CQRS環境での私の状況を取り入れるための最良のアプローチは何ですか？一部の人々は補償行動について話しますか？それは私を助けることができるものですか？

ありがとう。

イベントによって統合された複数のシステムがあり、それらすべてがイベント ソーシングを使用しているとします。イベントはどこに保存しますか?

私の場合、3 つのシステムがあります。

• ショップであるウェブサイト
• 顧客、製品などを管理する Web サイトのバックエンド。
• 会計システム

これらのシステムの 1 つでドメイン イベントが発生するたびに、イベントが公開され、他のシステムで処理できます。すべてのシステムがイベント ソーシングを使用しています。

イベントをどこに保存するのか疑問に思っています。もちろん、各システムは処理したすべてのイベントを保存する必要があります。これは、イベント ソーシングを使用しているため、一度処理したイベントに依存するためです。

しかし、必要がないためにシステムがサブスクライブしなかったその他のイベントについてはどうでしょうか。システムが持続しなかった過去のイベントを処理する必要があるなど、要件が変更される可能性があるという事実に苦労しています。発生時にサブスクライブしなかったイベントをシステムが処理する必要がある場合、これらのイベントをどこから取得しますか?

この時点で、イベント ソーシングを使用しないシステムとは大きな違いがあると思います。データに依存するシステム A に機能を実装する必要があり、それは A では利用できないが、別のシステム B では利用でき、NHibernate のような ORM ツールを介して現在の状態を永続化する場合、そのデータを A から B にインポートするだけです。 . イベント ソーシングを使用するシステムは、現在の状態に到達するためにイベントに依存するため、過去に見逃したが現在必要なすべてのイベントをインポートする必要があります。

私にとって、この問題にはいくつかの異なるアプローチがあります。

1. 各システムは、発行されたすべてのイベントを保存します。これにより、必要に応じてイベントを再公開したり、別のシステムにインポートしたりできます。
2. 各システムは、(まだ) 処理する必要のないものも含め、発生したすべてのイベントを保存します。
3. すべてのシステムからのすべてのイベントは、中央のイベント ログに保存されます。過去に発生したイベントを処理する必要があるが、サブスクライブしていない場合は、ここからインポートできます。

このような状況にどのように対処しますか？イベントをどこに保存しますか?

編集

Roy Dictus さん、ご回答ありがとうございます。次の状況を処理する方法がまだわかりません。

この Web サイトは、CustomerRegistered、CustomerPurchasedProduct、CustomerMarkedProductAsFavorite というイベントを発行します。バックエンドの現在のバージョンでは、顧客を表示する必要があり、その購入を表示する必要があります。顧客がお気に入りとしてマークしたものは、そのバージョンのシステムには関係ありません。したがって、バックエンドは CustomerRegistered と CustomerPurchasedProduct のみをサブスクライブします。

ここで、マーケティング部門は、お気に入りの製品に関する情報を顧客の詳細ページに表示することも望んでいます。バックエンドは CustomerMarkedProductAsFavorite をサブスクライブしていないため、この情報はバックエンドでは利用できません。その情報はどこから入手できますか?