CQRS/ES 俺的ベストプラクティス③

CQRS/ESにおける機密情報の扱いと削除方法

イベントソーシング（Event Sourcing）は、システムの状態変化をすべてイベントとして保存することで、変更履歴を完全に追跡可能にする強力なアーキテクチャです。

しかし、このアプローチにはひとつ大きな課題があります。

❗一度保存されたイベントは削除できない

イベントソーシングでは、ドメイン上のすべての状態遷移を「イベント」としてイベントストアに蓄積します。
このイベントはシステムの 唯一の真実（source of truthであり、原則として不変かつ削除不可です。

そのため、ユーザーが退会した場合などに発生する「個人情報の削除」要件に対して、
イベントソーシングはそのままでは対応が難しい構造となっています。

🔐 機密情報はどう扱うべきか？

イベントに「名前」「住所」「メールアドレス」などの機密情報や個人情報をそのまま持たせることは、将来的な削除や管理の観点でリスクになります。

この問題への対応として、以下のアプローチが有効です：

イベントに直接、生の機密情報を保存せず、暗号化して保存します。

これは、イベントのスキーマ情報を表している。ということにしてください。
CustomerCreatedEvent {
    customerId: "cus-123",
    encryptedName: "gG5kmv4fLsp8w==",
    encryptedEmail: "HJ4lkg67=="
}

暗号化・復号には鍵が必要です。
この鍵をユーザーごとに生成・保存しておき、以下のように管理します。

• イベント内の機密情報は「復号に必要な鍵」がなければ読めない

• ユーザーが退会したら、その暗号鍵を破棄する

• 結果として、イベントの中身は解読不可能（= 削除と同等になる

例：退会時(機密情報削除)の流れ

1. 該当顧客の暗号鍵を特定

2. 鍵ストアからその鍵を削除

3. 以降、その顧客に関するイベントは復号不能となる

4. イベントそのものは残っているが、中身が読めないため事実上「削除された」扱い