CQRSなにそれおいしいの?

完全にエンジニアの人向けです。

@bufferings さんのJJUG CCC 2017 FALLのスライド(p.73)を見て、「めちゃめちゃおもしろそう!!!」と思ったんですが、「なにが嬉しいのか?」の理解が及ばなかったので調べてみました。

f:id:uggds:20171122013506p:plain

https://speakerdeck.com/bufferings/spring-boottokafkadecqrs

CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」(副作用あり)と「クエリ」(副作用なし)でわけようという考え方

そこで、「cqrs メリット」で検索(答えおちてないかなー)

POSTDで以下の記事をみつけました。 postd.cc 下の記事を翻訳したもののようです。
http://blog.softmemes.com/2016/11/12/using-cqrs-with-event-sourcing/

ドメインモデルを使った「CRUD」ではなにか問題があるから、CQRSのアーキテクチャがでてきたと思うので、 知りたいのはまず、
ドメインモデルを使った「CRUD」ではなにか問題があるか?
です。

記事によると、

単なるCRUDではなくもっと細かい操作をデータ層で公開したい場合、たとえばドメインオブジェクト全体ではなく一部だけを操作するようにして、特定の環境で特定のフィールドを書き換えられないようにするといったことをしたい場合にCRUDでは問題がある

と言っています。

んー確かに。…に?

そこからさらに、そもそも
データの書き込みと読み込みとでは、検討すべきことが大きく異なるとあります。

f:id:uggds:20171122024815p:plain http://postd.cc/using-cqrs-with-event-sourcing/

あ!!なるほど!!

本来は書き込みと読み取りでは関心ごとが違うのか!

わけて考えたいのか!!っいうかわけて考えていいのか!!

CQRCでコマンドとクエリを分離することで、
データの書き込みと読み込みに対してドメインオブジェクトにしばられず別々に検討することができるから嬉しいということがなんとなくわかりました。

例えば、

  • クエリ側はUIに必要な情報を取得するためにやっていた結合とかをしなくてすむ
  • コマンド側はイベント「何が起こったか」という観点でデータストアとのやりとりを考えることができるようになる

?は残りますが、なんとなくつかめました。
めちゃめちゃおもしろそう!
※再度 @bufferings さんのスライドみると理解度がましましたー

さらなる疑問がでてきましたが、それはまた今度。

  • EventProcesserが複雑になりそう?想像ができない。
  • CoherenceってKVSだけど、こんな仕組みじゃなかったかな?関係あるかな?Readの方だけで使うとかあり?