SQLのドメインイベントストレージ... JSONのシリアル化を使用しますか？

Question

私は、最初の顧客と一緒に野生の中で遊べるようになる前に、既存のコードベースをリファクタリングすることを検討しています。現在のドメインイベントストレージ構造が本当に好きではありません。多数の非常に異なるイベントをRDB表に多く格納します。

アーキテクチャ：

• Webアプリケーション
• のJava
• 春4
• 春JDBC
• MSSQL

詳細：

• 40 + - それぞれが集約ルートまたはその子要素のいずれかに関連する異なるイベント。イベントの
• 詳細が格納されますが、いないオブジェクトの状態（これがないCQRSイベントソーシング）
• イベントONLY
• レポートは、Javaオブジェクトが供給されるレポートに使用されています。 IE。レポートはSQLから直接実行されません。

現在、イベントは制限付きコンテキストごとに1つのイベントテーブルに格納されています。すべての異なるイベントタイプに&データを保持するためには、テーブルのスキーマは、この

event_id long, 
event_type varchar, 
event_time datetime, 
context_1_key varchar, 
context_1_val varchar, 
context_2_key varchar, 
context_2_val varchar, 
context_3_key varchar, 

...ので、10倍...

のように繰り返して、例えば（オーダー=集約ルート、項目=子供のように見えます）

event_type=ITEM_OPEN 
context_1_key=ORDER_ID 
context_1_value=1000 
context_2_key=ITEM_ID 
context_2_value=2000 

いいえ私はそれが好きではありません、そして、私はそれを行う責任がありませんでした。

問題：

• context_1_xxxフィールド
• （報告は、パフォーマンスに敏感でなくても）一つのテーブルに詰めトラブルシューティング/拡大
• すべてがパフォーマンスの問題になります/維持するために壊れやすく、困難なイベントドメインオブジェクトにリンクされています。それらはオブジェクトの状態を保存しません。例えば。アイテムが削除された場合、記録されたイベントは役に立たなくなります。

各イベントに固有のスキーマを持つ40種類のテーブルを作成すると、答えがわかりません。代わりに私は、イベントデータと共に保存されるドメインオブジェクトのスナップショットをシリアル化（JSON）することを考えていました。

• 我々はすでに、ブラウザベースのクライアントのためのオブジェクトをシリアル化するために春/ジャクソンモジュールを使用します。
  それは便利なソリューションと思われます。
• チームは、シリアライズ/デシリアライズプロセスにかなり慣れているので、大きな学習曲線はありません。
• イベントデータは、私が見ることができる唯一の本当の欠点があり、デシリアライズジャクソン

とすることにより十分に簡単になりますレポートを生成するためのバックアプリケーションを介して行かなければならない： - SQLベースのサードパーティ製を使用することができませんレポートツール - ストアドオブジェクト（JSON）のプロパティでテーブルをインデックスに登録できません

イベントストレージをさらにいくつかのテーブルに分割することで、やや軽減できます。

他に何が欠けていますか？これを達成するための確立された最善のアプローチはありますか？どうやってやるの？

Answer 1

Building an Event Storageで始まる、Greg Young。

Konrad Garusは、PostgresSQLを使用するイベントストアを表します。

私の腸は、各イベントに固有のスキーマを持つ40種類のテーブルを作成すると答えはありません。

おそらくそうではありません。最初のカットは、すべてのタイプのイベントの単一のテーブルでなければなりません。イベントデータのBLOB（json is fine）と、イベントメタデータのBLOB（類似のBLOB）があります。次に、順序付けられたイベントの履歴を正確に抽出するために使用する一連の列があります。

代わりに、イベントデータと共に保存されるドメインオブジェクトのスナップショットをシリアル化（JSON）することを考えていました。

これは奇妙なフレーズです。イベントデータのJSON表現ですか？それは理にかなっている。

「スナップショット」は眉毛のライザーですが、イベントデータのスナップショットは必要ありません。イベントは不変であるためです。あなたは間違いなく、状態スナップショット（すなわち、イベントの履歴をロールアップした結果）をイベント自体と混合することは望ましくありません。

フォローアップ：GetEventStore .NETクライアントwritesとreadsのイベント履歴が、どのようにしてスキーマを設計するかについてのさらなるアイデアを提供する方法を見てください。イベントデータ/メタデータがブロブとして処理されていることに注意してください。