吉祥寺.pm様主催の設計ナイト2020に参加してきました。
ついていけてない部分もあって全部覚えきれていませんが、これ以上忘れる前に書き留めておきます。
CQRS+Event Sourcing
最初はかとじゅんさんによる発表でCQRSとEvent Sourcingについての説明でした。資料は以下のリンクです。
https://speakerdeck.com/j5ik2o/event-sourcingwojie-shuo-suru
まとめると以下のような内容でした。
- CQRSは境界を引いてCとQを完全に分断しなければならないので、コストがかかる。
- Event Sourcing無しでCQRSは難しい。
- コストをペイできるほどの大規模なものや、耐障害性を求めないならやらないほうがいい。
かとじゅんさんが提示されていた現実解は私もよくやっていました。WEBサービスをベースに考えますが、そもそもクエリパラメーターによって条件を変化させたり、ページネーションのような取得件数の上限を設けたりしなければいけないGETリクエストと、ドメインロジックによるほぼ固定された条件によるデータ取得しかしないその他で同じモジュール使ってデータ取得すると、どっちかに負債ができるので、最初から別々のモジュール使ったほうがいいと思ってます。ただ、かとじゅんさんが提示されていた現実解ではクエリでドメイン側のVO使うとされてましたが、私は全て禁止してました。基本的にはデータ設計はイミュータブルデータモデル(入門編,世代辺)をベースにしてるのですが、クエリ用に非正規化されたテーブル用意したりもしますし、クエリ側にコマンドのVOのロジックが影響を及ぼすのは嫌だったので。DRYではないのでは？と思うこともありましたが、そこは許容範囲だと思ってます。
イベントストアについては、チャット欄含めていくつかおすすめされてました。
- HBase
- Kafka
- Datomic
今後Event Souringやることになったら参考にしてみようと思います。
GraphQL
qsonaさんの発表はGraphQLについてでした。資料は以下のリンクです。
https://hackmd.io/@jnl1y8gDTkq7ywsLXpa6GQ/HkDGObSOP
GraphQLについてはクライアントサイドもサーバーサイドも扱ったことがないので、あまりついていけてませんでした。
ただ、具体的な実装についても資料で提示されているので、今度自分で作ってみてもいいなと思いました。
BFFでGraphQLを使うという意見もありましたが、こちらについては「BFF自体がフロントエンドの特定のユースケースを満たすという目的で作られるものなので、あらゆるクライアントサイドで好きにやらせる目的で作るGraphQLとはニーズが合わないのではないか」という意見があり、これには納得しました。
まとめ
こういう設計の話は大好きなので、こういうイベントもっと参加したいのですが、中々ないのですよね。(探し方が悪いだけかもしれませんが)
もっと話ついていけるように、プログラミング言語だけでなくストレージとかキューとかの技術をもう少し触っていこうかなと思いました。