EventをLong Term Eventで表現するパターン

おそらく@kawasima氏の造語

参考

『WEB+DB PRESS Vol.130』 p.28~

いくつか、疑問、疑念(?)がある

Long Term Eventという概念を入れる必然性

どっちの方向から入ったのかわからないが

入会 というEventがあるな→実はこれは3つのEventで構成されているので分けれるね

入会申込 、 審査 、 会員証発行 というEventがあるな→これを抽象化すると 入会 と表現できるね

いずれにせよ、複数のEventで構成されたEventを定義することの嬉しさが腑に落ちてない

そこが腑に落ちれば、それの表現方法のひとつとしてLong Term Eventがあることを納得できるかもしれない

なんというか、もっとシンプルに表現する方法があるような気がする

残のような視点

抽象化として成立してるのかどうか

個別に扱った場合にどういう問題が起きるのか

仮に、複数のEventで構成されたEventがあったとして、それを別のテーブル?で構成する意義

入会申込 、 審査 、 会員証発行 というEventをUnionで表現して、全部1つのテーブルに突っ込む

というのも考えられるはず

これを採用するとどういう課題が生じるのだろうか

こっちのほうが、JOINなども不要だし、readもwriteも単純になりそうな気がするが

(ただこれはデータを全てJSONで表現するのを前提している)

テーブルごとにスキーマを定義するなら、RDBMSだと、テーブルを分けるしかないというのはわかる

分けていれば、それをさらに入れ子にすることはできそう

入会申込 と 審査 は独立するので影響なしに変更できる

Resource Entityの履歴や世代を、immutableに如何に管理するか

一言でなんなのか？を書いておきたい

statusを別途保持すればいいのか