コマンドが失敗してはならないことはわかっているので、コマンドを送信する前にコマンドを検証する必要があります。
ただし、2人のユーザーが同じ集約ルートを更新していて、両方が有効であると思われる場合は、同時実行の問題が発生します。
NEventStoreでこれを処理するにはどうすればよいですか?クライアントは、イベントの保存時に渡すバージョン番号またはコミットIDを取得する必要がありますか?それが変更された場合は、例外を発生させますか?
コマンドが失敗してはならないことはわかっているので、コマンドを送信する前にコマンドを検証する必要があります。
ただし、2人のユーザーが同じ集約ルートを更新していて、両方が有効であると思われる場合は、同時実行の問題が発生します。
NEventStoreでこれを処理するにはどうすればよいですか?クライアントは、イベントの保存時に渡すバージョン番号またはコミットIDを取得する必要がありますか?それが変更された場合は、例外を発生させますか?
あなたがほのめかしたように、物事を管理する1つの方法は、集約するときに動作することを期待しているバージョンを指定することですLoad
(それには過負荷があります)。
コミットフェーズでは、生成されたイベントがイベントと衝突した場合、[ドメインを介して]がConcurrencyException
生成されます。-
NuGetパッケージがプロジェクトに配置する.docファイルを1回以上読み取るようにしてください。これは、JOEventStoreがこれを処理する方法の基本をカバーしています。
明確にするための更新NBこれはすべて機能し、必要な場合もありますが、一般に、コマンドを自然に作成することで、これらの競合解決のほとんどを管理できることがわかります[デフォルトでは、幸せな場所に到着するために一生懸命働いているはずです]そのような低レベルのガードを提供するためにイベントストアに頼る必要がないようにするために、本質的にべき等であり、および/またはシステム全体で自然な競合解決メカニズムを使用する(例えば、etags、競合の場合のコマンドの再試行など) 。実際にこの道をかなり進んでいることに気付いた場合は、DDD-CQRSリストにある十分な実際のユースケースを使用して戦略について話し合うことをお勧めします。