Event Sourcingを使用してイベントを保存する

Question

イベントソーシングについて読んできましたが、いくつかの問題ではかなり自然なアプローチでしたが、実際にイベントを格納する方法はあまり理解できませんでした。

インターネットでちょっと検索すると、Vaughn Vernonのthis articleが、DDDでの集約の簡単な方法について話しています。イベントソーシングに関するものではありませんが、PostgreSQLを使用してドメインイベントを保存する方法を目的としています。

彼のアプローチでは、のテーブルEventsとJSON dataフィールドがあります。 JSONデータを保存できるため、さまざまなイベントを保存することができます。

しかしすべての集計単一のテーブルでに対応するすべてのイベントを持つ、私は少し心配になります。

イベントソーシングを使用するイベントを保存する場合、どのように進める必要がありますか？私は3つのオプションを見ることができます：

1. 記事のドメインイベントに使用されているアイデアに従い、すべてを単一のテーブルに格納します。

2. イベントごとに1つのテーブルを作成します。ここでの欠点は、各集約のイベントを追跡する必要があり、集約ごとにさまざまな種類のイベントが存在する可能性があることです。これは簡単に大きなテーブル番号につながります。

3. 集約ごとに1つのテーブルを作成し、そこに集約のすべてのイベントを格納します。我々は同じテーブルにまとめられたさまざまな種類のイベントに終わるが、それらはすべて同じ集約に関連している。

これら3つのオプションのどちらがより妥当でしょうか？そうでない場合、イベントソーシングを使用するときにイベントを保存する正しい方法は何でしょうか？

Answer 1

しかし、すべてのアグリゲーションに対応するすべてのイベントを1つのテーブルにまとめると、少し気になります。

FUDのようなサウンドです。

すべてのイベントは同じように見えますか？データの塊、および文脈内に塊を配置するのに有用なメタデータのいくつかの列。あなたは特に巧みな関係を築く必要はありません。ストリーム内のすべてのイベントを検索し、コマンドによって引き起こされたすべてのイベントを検索します（これらのイベントはすべて同じストリームに存在します）。

イベントはおそらくすべて同じ論理ビューに属します。

物理的には、縮尺を変えることができます。あなたはUdi Dahanが何を言っていたのかをCQRS but differentslidesに再検討することができます。しかし、ここでの基本的な考え方は、シャーディング/ partitioningがデータベースベンダーがすでに解決のビジネスに参加しているという問題だということです。Postgresのイベント・ストアの

議論：

• Konrad Garus
• Jeremy Miller