2

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

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

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

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

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

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

4

1 に答える 1

5

  1. 与えた例では、実際には複数の作業単位が発生しています。アグリゲートが変更されると、イベントがディスパッチされます。他の誰かがそのイベントをリッスンし、別の作業単位などを処理します。

    EventStoreの設計方法では、シナリオに対応できますが、3つの別々の作業単位になります。UdiのDomainEvents「Salvation」ソリューションを独自のIPublishEventsの実装にプラグインし、それをAsynchronousCommitDispatcher内で実行するだけです。真のDDDでは、単一のアグリゲートが作業単位です。定義上、これは整合性の境界です。

  2. 約8時間前、私は編集の一部として流暢なものを含むプッシュを行いました。マスターから最新のものをプルダウンしてみてください。

  3. IStoreEventsはマルチスレッド化されるように設計されているため、アプリケーション内でシングルトンとして安全に構成できます。IStoreEventsからセッションを開く場合、セッションはシングルスレッドであり、アプリケーション内のスレッド間で共有しないでください。

于 2011-03-22T11:18:35.963 に答える