CQRSとはステートマシンであることを導く

法則、前提

値、イミュータブルは良い

補題

値指向で設計するためには、read とwriteを分けないといけない

理由

ReadとWriteが同じ型、同じテーブルであると仮定する

場合分けする

もしも、既存のレコードや値を上書き出来る場合

当然、レコードは値ではなくなるので、値指向でなくなる。

上書きできない場合

writeはinsert onlyである

google formのようなものをイメージするとよいだろう。

型があり、appendされ、それらを読むことができるが、変更はできない

このモデルでは、変化しうる状態を表現することができない

それは、readとwriteが同じ型であるという前提に反する

このようなケースも、のちのreadとwriteを異なる型とみなすことと同じになる

以上より、値指向でやるためには、read とwrite両者は異なるべき

では、readとwriteが異なるとはどういうことか？

write

(イミュータブルな)値を書き込むとはなにか？

これは、「事実」とみなすことができる。

こういう値が保存された、という事実である。

イミュータブルで、データを保存し続ければ、これは未来永劫変わらない

実際、事実抜きでシステムを作ることは不可能だろう。

ユーザがなにかシステムに働きかける、アクションを起こす、

こういうのは、それは「AさんがXというアクションをした」という事実である

なので、ここでは事実を軸に置く

事実はイミュータブルなので値である

もちろん、事実に限らず、値であるものは、システムを構築する上で必要だし、色々あるだろう

しかし、それらもかならず、何かの事実に紐づくはずだ

readとは？

事実をreadすることもある

しかし、事実だけでない。

補題１

事実に基づいて、異なる情報を導く必要がある

理由

我々は、事実をreadしたいが、別の情報もreadしたいはずだ

事実しかwriteしてないのだから、別の情報とは、事実から"導かれた"情報であるはず

task created, task completed, から、完了済みのtaskという情報が読み取れる

補題２

事実とは、時間軸を有する。

よって、シーケンシャルであったり、配列、リストのように見なせる

また、その配列は、時間軸に沿って堆積するものである

一度に配列がタプルのようにドッと発生するのではなく、段階的に事実が積まれていく

よって、補題１でいう「事実に基づいて異なる情報を導く」というのは、

「事実の配列　→　情報」という関数と見なせる

このとき、引数の方の事実が、単一でありえなく、ストリームのように様々な事実が堆積していく

よって、返り値の情報は、その時々の情報が存在する

すなわち、ここでいう情報とは、状態を有している。

readとは、状態をreadしているのである

事実の配列から、状態を導くというのは、ステートマシンと見なせる

すなわち、readとwriteを分けるということは、

イベントをwriteして

ステートマシンとして処理して現在の状態を導き

状態をreadする、

と捉えることが可能である。

ーーー

実際のアプリケーション開発における設計、概念モデリングをする際は、

事実の設計

事実を表す情報の型を定め

状態の設計

何の情報がほしいのか、何をしたいのか

さらに、それに基づいてどんなアクションをしたいのかを考える

アクションを事実としてまた記録するので、事実の設計にフィードバックされる

両者をつなぐように、ステートマシンのコードを書いてみる

reducerなスタイルで書く

あとは、事実を集積する永続化層をRDBとしてテーブル設計をして

必要に応じて状態をキャッシュしたり検索したりするためのread側のテーブルを別途足していけば良い

ただし、過去の状態をいつでも再現できるようにしたり、時系列を通して検索したい場合とか、要件によってread側は難しくなる

単に現在の状態を示したいなら、簡単

素朴なテーブル設計で実現ができるだろう

また、DBのread write storageコストと、それらの情報の価値をちゃんと比べる必要があり

価値が低い分、情報を減らしてコストを削減する、という観点も必要だろう

ここで分かったをrefainして書き直した