イベントエンティティのライフサイクル

イベントエンティティは、シンプルなケース、すなわち単純なイベントの連なりを記録すればよい場合は、後続のイベントが先行イベントのIDを持つことで表現される。

例えば、「問合せ」イベントに対する「回答」イベントのように。

https://gyazo.com/796c92b89a0e2e2a4f946b6d39f6b0aa

だが、実際の業務システムでは、「各問合せの状況を一覧化し、滞留している問合せがないか把握したい」みたいなユースケースがある。そうなると「問合せ」は状況(ステータス)をもち、実際の「問合せ登録」や「回答」のイベントによって、それが変わっていくというモデルが形成される。

実装からみればこの「問合せ」はイベントを積み重ねた結果の"キャッシュ"であり、データ量が少なければ、実際にテーブルなどを作らなくても現実的な性能でクエリできるかもしれない。が、実際に業務として「問合せの状況を把握する」として、「問合せ」エンティティを認識しているので、メンタルモデルを表現するとしてもこの形になるのが自然だ。

私はこの「問合せ」に相当するものを、ロングタームイベントと呼んでいるが、これはあくまでも「コト」のモデル化であって、リソースとは区別したいが、ライフサイクルをもちイベントによって状態が更新される点において、リソースと同じふるまいをする。

https://gyazo.com/4fc77d47fd2aa5d26463f886d710294c

同種のイベントが複数回発生したり、イベントが別のイベントによって無効化される場合、ロングタームイベントから見たときの「現在有効なイベントというものが存在し、それがあるイベントによって変わりゆく」ということになるので、以下のように、各イベントによって「有効問合せ内容」や「有効回答内容」が更新される、とモデル化するとよい。

https://gyazo.com/32258b1f7b74a4ab29eac57b1ce6b3c6