5

おなじみのイベント ソーシング パターンを使用してサービスを構築しています。

  1. リクエストが受信されます。
  2. アグリゲートの履歴がロードされます。
  3. アグリゲートが (その履歴から) 再構築されます。
  4. 新しいイベントが準備され、手順 1 からの着信要求に応答して集計が更新されます。
  5. これらのイベントはログに書き込まれ、すべてのサブスクライバーが利用できるようになります (発行されます)。

私の場合、ステップ 5 は 2 つの部分で完了します。イベントはイベント ログに書き込まれます。バックグラウンド プロセスは、イベント ログから読み取り、オフセットから始まるすべてのイベントを発行します。

場合によっては、集計に関連するイベントに加えて、副作用を公開する必要があります。システムに関する限り、これらは他のサービスによって消費され、他のサービスの状態に影響を与えるため、イベントでもあります。ただし、このサービスの集計の履歴には影響せず、再構築する必要はありません。

コードでこれらをどのように処理すればよいですか?

オプション 1 - 副作用のあるイベントをイベント ログに書き込まないでください。ステップ 5 の前に、メイン プロセスでこれらを公開します。

オプション 2 - すべてをイベ​​ント ログに書き込み、履歴が読み込まれるときに副作用のあるイベントを無視します。（これらは歴史の一部ではありません！）

オプション 3 - 副作用のあるイベントをダミーの集計に書き込み、公開されても読み込まれないようにします。

オプション 4- ?

最初のオプションでは、同時実行違反があると問題が発生する可能性があります。ステップ 5 で書き込みが失敗した場合、副作用を簡単にロールバックすることはできません。2 番目のオプションは、集計の履歴の一部ではないイベントを書き込みます。ステップ 2 でロードするときは、これらの副作用イベントを無視する必要があります。3番目のオプションはハックのように感じます.

これらのうちどれが正しいと思いますか?

4

3 に答える 3

5

イベントに正しく名前を付ける

イベントは「起こったこと」です。したがって、「X が起こった」ような副作用のみを引き起こすイベントに名前を付けることができれば、それらはイベント履歴の自然な部分になります。

私の経験では、これはいつでも可能です。名前が少し人工的になる場合もありますが、「そのクライアント イベントに電子メールを送信する」などと呼ぶよりも、そのようにイベントに名前を付ける方が適切です。

代替案のリストに関しては、これはオプション 2 になります。

例

イベントを「ステータス メールを顧客に送信するイベント」と呼ぶ代わりに、「ステータス メールがトリガーされるイベント」と呼びます。もちろん、実際のトリガーのより良い名前があれば、それを使用してください:-)

于 2016-01-05T06:19:46.153 に答える
1

オプション 4 - 他のサービスにイベントをサブスクライブさせ、副作用とそれらに関連する追加のイベントを生成します。

イベントはきめ細かくする必要があります。

于 2016-01-05T06:08:46.263 に答える