CQRS/ES：一括操作/インポート

Question

私はCQRS/ESのアイデア全体を頭に入れようとしており、現行のアプリケーションで実装する方法の概念と技術仕様書を書くことを検討しています。

問題のある操作（CQRS/ESにマップする方法）は、ファイルインポートによる複雑な記事データの一括更新 - 記事ファイル、記事、ヘッダー、ユニット、およびプロパティ、バイヤー品揃えをサプライヤー品揃えにリンクするファイルの一括読み込み、および揃え品の一部または全部のエクスポートを行います。

記事のインポートBC（Excelファイルやその他のグリッドファイルを読み込みます）をモデル化する最良の方法は、インポートされたデータの1行を作成することだと思っています（DDDCQRS Googleグループでした）。集計、およびインポート全体が集約ルートになります。こうすることで、ファイルを解析した後、インポート集約を作成し、各行に対してその行をインポートに追加するだけです。これにより、BCのイベントストアにイベントが保存され、BCが購読する予定のイベントが公開されます。これは理にかなっていますか？

現在のシステムでは、インポートは1つの長期実行トランザクションで実行されます。ロングランニングは、インポートされるデータの量と、以前にインポートされたファイルおよび現在のデータと比較されるため、特定のユーザーに既に存在するデータの量に応じて、5〜40分の間で読み取る必要があります。操作の途中で失敗すると、現在は操作全体がロールバックされます。 CQRS/ESではどのように機能しますか？

Answer 1

CQRS/ESを搭載したリトルトドゥ非常に単純なアプローチは、以下：

は、これらのユニットの昇順識別スキームを考案

• 仕事のあなたのユニットを検索し、
• が（速い&に失敗する可能性が低い）仕事のこれらのユニットに元の入力を変換します
• 各作業単位をトランザクションとして処理し、最後に処理された作業単位のIDを各トランザクションの一部として更新します（並列処理する場合は複数）。
• 障害発生時最後のプロから再開する自動的にまたはopsが緑色の光を与えた後に、後続の作業単位を続けます。

劣悪なIMOの背後にイベントソースまたは状態ベースのモデルがあるかどうか。