CQRSとイベントソースを使用する際の一意性検証

Question

イベントソーシングを使用して独自のCQRSインフラストラクチャを実装しようとしています。サンプルプロジェクトとして、私はブログエンジンを実装していますが、完璧ではないかもしれませんが、本当のものに取り組んでいきたいと思います。

私が今問題にしたのは、検証です。すべての投稿にshortUrlがあり、shortUrlは一意である必要がありますが、この確認はどこでドメインに置くべきですか？私は、ポストコマンドの作成やポストコマンドの更新の作成時に有効かどうかを確認するために、私の読者から読んでコマンドを送信する前に、その検証が済むことを知っています。

私は2つの "解決策"を考えることができます。

1. は、すべてのブログ関連の設定もすべてのポストへの参照のトラックを保つBlog集計を持っています。しかし、私の目では、このシナリオでの集約間のやりとりと、その固有性を検証する必要があるたびにコミュニケーションを処理する必要があるということが私の目にあります。すべての投稿を作成するには、イベントストアからすべてのイベントを読み込む必要があります。それは複雑に思えます。
2. 私が持っているもう1つの選択肢は、イベントが発生し、読み込みモデルを作成するイベントハンドラが、異なる投稿を指し示す2つの短いURLを持つことに気づいたときに、短いURLイベントを発生させることです。エラーを検出したときにイベントを発生させる読み込みモデルを持つことは有効ですか？

これ以上の代替手段はありませんか？私のドメインはcqrsとDDDにとって最適ではないかもしれないことは分かっていますが、小さなドメインで学ぶためにこれをやっています。

Answer 1

「ビジネス」が何をしたいのかによって異なります。クライアント（コマンドの作成者）が短いURLの選択を担当するようにするには、そのURLの一意性を検証する読み取りストアが必要です。ユーザーが短いURLを入力すると、ビューは短いURLが一意であることを確認し、そうでない場合は検証エラーを表示する必要があります。投稿が保存されるたびに、イベントは、更新された情報（短いURLを含む）を公開して、読み取りストアを同期させた状態にします。

Answer 2

私は、一意のShortURLを生成する責任があるドメインサービスに行きます。トランザクションDBを使用してこの動作を実装できます。通常、このサービスはBlogPost集約のコマンド処理部分で使用されます。 ShortURLが重複している場合は、DuplicateUrlErrorEventを発生させることができます。 同じデータソースを使用してシン・クエリー・モデルを作成することで、これをUIで事前に捕捉できます（ただし、決して100％）。@ RyanR's回答）。

Answer 3

これと関連する質問に関するさまざまな回答を読んだことがあります。

正しいかどうかの判断が下がります。あなたが許して、ある程度の操作で不完全な振る舞いを受け入れることができれば、あなたの問題は、特に弱い一貫性の保証の下で、解決するのがはるかに簡単です。

ただし、一貫性が必要な場合は、一貫性の保証が高い永続性サービスを使用する必要があります。

たとえば、短いURLを作成するコマンドでは、読み取りストアにこのような短いURLが含まれていないことが検証され、最初に読み取りストアに変更をコミットできる場合にのみイベントがコミットされます。

読者が変更をコミットすることができれば、一意性の制約に違反していないことになります（読者がそのような制約を強制すると仮定した場合）。

しかし、2つのトランザクションが同じデータベースにあるとは限らないため、最初のコミット後に失敗する可能性があります。操作が全体として失敗するため、これは問題ありません。読み取りストアはしばらくの間、不一致の状態を反映しますが、修理となると、読み取りストアは一貫した状態に戻ります。

潜在的なエラーの可能性がある集約を定期的に修復することができます。そして、両方のトランザクションが正常にコミットされた場合にのみクリアされるエラーフラグを導入することで、これを行うことができます。

補償するための追加料金があるため、銀行がユーザーのアカウントを上回ることができるようにする例がありました。このような問題を解決することは怠け者だから、これは疑問を生む。スマートと呼ぶ者もいます。私は何を考えるべきか分からない。銀行はおそらくそれをカバーするのに十分な資金を持っているので、無視するかもしれないが、世界は現在どのように働いているのか分からない。とにかく、私は逃げる。

正確性の観点から、当社のリードストアは一貫性の保証が強く、残高がマイナスの場合はリードストアにトランザクションをコミットできないように予測を記述します。このように最悪の事態は、読み込みストアから料金が控除されたが、イベントストアでその操作が完全にコミットされなかったことである。メンテナンス手順でエラーフラグが認識され、アカウントが修復されるまで、ユーザーはアカウントから不足している金額を確認します。これは私が思うに、妥協案です。