仕様パターンでのイベントソース集約ルートの使用
リポジトリ内の一連のイベントから構築されるイベントソーシング手法を使用する集約ルートがあります。これは、状態の変更などを管理する必要がある場合に最適ですが、仕様パターンを使用してアプリ固有のビジネスルールを適用するようになると、使用するエンティティ、それらをインスタンス化する方法などについて壁にぶつかります。 。
getProductByProductCodeなどの特定のメソッドをリポジトリで実行したいので、現在のARをチェックして一意性を確認します（簡単な例）が、リポジトリが設定されているため、これを行う方法がわかりませんイベントストアからIDでARを取得します。
以前はリポジトリをバッキングするデータベースがありましたが、まだ読み取りモデルがないため、現在はイベントストアしかありません。
- 誰かがこれを以前にやったことがありますか、そしてあなたはそれをどのように行いましたか？
- 最初に読み取りモデルが必要ですか？
- 読み取りモデルにクエリを実行し、結果のIDを使用してイベントストアからARを取得する必要がありますか？
- 複数のAR結果を返す必要がある場合はどうなりますか？
私は、イベントソーシングが必要なので、今はちゃんとやっていると思っていたので、とても混乱していますが、昔ながらの考え方と、イベントソースを使った方法でそれを実現する方法をうまく組み合わせられないようです。
イベントストアからIDでARを取得するようにリポジトリが設定されています。
それで十分でしょう。リポジトリからARsのコレクションをクエリする必要がある場合は、特別に設計された_Read model_を使用する必要があります。
つまり、CQRSを使用しています。つまり、Aggregateをクエリして_product code_であることを確認することはできません。また、基本的にはAggregatesのコレクションであるリポジトリもクエリできないのは当然です。
誰かがこれを以前にやったことがありますか、そしてあなたはそれをどのように行いましたか？
私はこの質問にのみ答える高速で特別な設計の読み取りモデルを作成します：bool isThereAlreadyAProductWithThisCode(string productCode)。
最初に読み取りモデルが必要ですか？
はい。上記を参照。
読み取りモデルにクエリを実行し、結果のIDを使用してイベントストアからARを取得する必要がありますか？
コマンドを送信する必要がある場合のみ。集計には、コマンドメソッドのみがあります（クエリメソッドはありません）。
複数のAR結果を返す必要がある場合はどうなりますか？
次に、新しいクエリを作成するか、上記の読み取りモデルを変更して、このクエリに回答します。
私は、イベントソーシングが必要なので、今はちゃんとやっていると思っていたので、とても混乱していますが、昔ながらの考え方と、イベントソースを使った方法でそれを実現する方法をうまく組み合わせられないようです。
あなたが取らなければならない2つの飛躍があるので、それは難しいです：
CQRS：コマンドのみを受け取る書き込みモデルがあります（
voidを返すメソッド）。クエリメソッドはありません。 DDDでは、これはAggregateであり、そのエントリポイントは_Aggregate root_です。 1つ以上の読み取りモデルもあります。他のレイヤー（プレゼンテーション、アプリケーション、インフラストラクチャ）からの質問に答えるクエリメソッドがあります。イベントが発生したときに永続化状態を更新するメソッドもありますが、これらのメソッドは他のレイヤーでは使用されません。イベントがすべての読み取りモデルに適用された後、それらは破棄されます（書き込み側では使用されなくなります）。コマンドが到着すると、Aggregateは、最後のコマンドが処理されたときにプレーンな状態が保持されていたリポジトリからロードされます。イベントソーシング：書き込みモデル（DDD集合体）では、永続的な状態はありません。コマンドが到着するたびに、Aggregateのクラスを
new- ingしてから、それ自体の以前に発行されたイベントをすべて適用することにより、イベントストアによってAggregateが再隠されます（snapshotingと呼ばれる最適化がありますが、機能しますちょうどキャッシュのようで、本当に必要でなければ、避けるべきです）。イベントストア以外の集計状態を含むデータベースはありません。