読者です 読者をやめる 読者になる 読者になる

考える場所

ココロとカラダ、思考する全部

CQRSの小さな演習(last) CQRS

ドメイン駆動設計 CQRSの小さな演習

前回まではコマンド側のクラス構成を中心に見てきました。今回はクエリ側も含めてデータ取り扱い方を俯瞰して考えてみたいと思います。

クエリ

クエリは画面表示上の都合のためにあります。クエリ側のオブジェクト(以降、DTO)とコマンド側のオブジェクト(以降、ドメインオブジェクト)を別々に考えるのは、単純な話、画面表示させたい情報がドメインオブジェクトではないからです。たとえばページ番号やソート情報などはドメインオブジェクトとしては不要だったり、内部的なステートはDTOとしては不要だったりします。

The fundamental difference is that in CQRS objects are split into two objects, one containing the Commands one containing the Queries.
-- CQRS Documents by Greg Young

CQRSはCQSに対して、クエリをもつオブジェクトとコマンドをもつオブジェクトを別ける、というところに違いがあるようです。(CQSはクエリであるメソッド呼び出しに副作用があってはいけないということを言っている??)

演習では、DTOを取得するためのインタフェースを(伝統的な)DAOという名称にしました。ドメインオブジェクトを取得するためのリポジトリとは別のインタフェースです。画面表示させたい情報が非正規化したものであるときは、非正規化した型のDTOを設けてDAOから取得できるようにします。ドメインオブジェクトだけでこれをすべてやろうとするのは複雑過ぎです。

イベントソーシング

さて、コマンド側ではイベントを起すことまでしか考えませんでした。イベントは追加のみで不変なので、トランザクションがシンプルになります。また、イベントをすべて残すことができまた追うことができれば、完全な履歴を残すことと同時に結果整合性を保てるメリットがあります。何が起こったかというイベントがあるのですから、すべてを足し算すれば今どうなっているかというステートを得ることができる訳です。イベントソーシングは、イベントを追加し続けて、必要なときにイベントを追ってステートを組み立てることができるようにするものです。

f:id:fukuchiharuki:20160814175037p:plain

CQRS

ここまでのお話にいろんなモデルが登場しました。まずはドメインオブジェクトです。ドメインオブジェクトはコマンドを受けてイベントを起こします。画面表示のためのDTOはイベントから組み立てるステートです。しかし、画面表示のためにいつもイベントからステートを組み立てるのは非効率ですから、リードモデルを設けてイベントをステートとして射影しておきます。従って、DTOはシンプルにリードモデルを取得したものになります。

f:id:fukuchiharuki:20160625105727p:plain

演習ではイベントソーシングをやってみたかったわけではないので、ドメインオブジェクトがイベントを起こすようにモデルを設計したものの、イベントをすぐさま射影してステートを永続化するようにしました。永続化の仕組みをイベントソーシングにしたとしても、リポジトリとDAOの実装がそのようになるだけで、ドメインオブジェクトやDTO周りの設計はそのままになるはずです。

おわりに

7回に渡って、CQRSの自分なりの理解を整理してみました。実際にコードや記事を書いて、こういう理解で大丈夫なんだっけ?と考えてみることは何より自分のためになったなと思います。マイクロサービスという言葉も話題になっていますし、シンプルな設計は複雑化するシステム開発を背景にますます注目されていくことと思います。

次のスライドでこの記事を参考として挙げてもらっています。ありがとうございます。

最初

blog.fukuchiharuki.me

面接は化かし合いなの?

思ったこと 考える練習 仕事

面接は化かし合いだなんて揶揄も聞くど、そういう面は否定できないんだろうなと思う。だいたいそういう話題では、学生がいかに盛っているかみたいな見方だけど、企業だって変わらない。風通しってなに、高層ビルなのに窓開けてるんですか?wって学生は聞いてみたらいいよ。

バイトリーダーとかキャプテンとか、どんだけいるんだよって話は、確かにそうだなという気がする。いくらかの人はやってないのにやってると言っているのだとは思う。それを浅はかな嘘だと罵ったりするのはもうやめにして、本当に浅はかなのかと問いたい。実は企業が「即戦力」とか「リーダー不足」だなんて言っているから、学生(あるいはサポートする何か)だってそういうのが響くんだって見てるわけでしょ。ただただ学生がバイトリーダーをやりだしたりしているのではないはず。そういうことを言って欲しいと思ってしまっているところがあるんじゃないかな。

いろんなことが安易に済まされるようになってきているように感じる。面接で何を聞けば学生の本質を見抜くことができるかって、そういうものの見方こそ浅はかなんじゃないの。その時自分の頭で言葉を選んで口に出して耳で聞いてまた考えて、そういうのをすっ飛ばしてどういうフレーズで聞くのがいいのかと考えるのは、何を言って欲しいかって最初から決めてるってことだよね。そうしたら、学生だってバイトリーダーとかキャプテンとか言いたくなるのも無理はない。

どこかで、この人はどういう属性値を持ってるのかって測り方をしてしまっている。リーダー向きか、エンジニア向きか、とか。企業の抱えている問題が本当に「リーダー不足」であるのだとしたら、リーダー向きの(ことを言ってくれる)学生を迎え入れることが本当に解決になるのかはちゃんと省みたほうがいい。社内でリーダーを生み出すことのできるシステムに、この人を組み入れたいと思うか。くらいには考えてみたい。新人ががんばってやっていくっていうのと同じように、企業だってそういう働きかけをしていくっていうのは、それはお互いの責任なんでしょ。

この化かし合いは、何か違った力がはたらかなければ加速していく一方だと思う。楽をしようとして得た結果が自然に改善されていくということはまずないだろうから。先に考えなきゃいけないのは、社内の仕組み(教育とか?)をどうしていくかってことなんじゃないかな。その基盤があるからどういう人を迎え入れたいかってことが初めて考えられるのだと思う。そうでなければ、始めから特性をもった新人が救世主をやってくれることに期待するってことに、なってしまうよね。

合わせて読んでほしい

blog.fukuchiharuki.me

活字を避けて自由を考える

変えたこと 思ったこと 考えたこと 読んだ本

ゴールデンウィークに実家へ帰ったとき、活字を意識的に避ける、ということをやってみた。ノートパソコンを持たないようにしたし、本も持たない。携帯はさすがに要るから持ったけどなるべく見ないようにした。持って行ったのはカメラとレンズだけ。

やってみてまず思ったのは、気がついたら携帯を持ってTwitterのアイコンをタップしてしまっているということ。ハッとしてすぐに閉じるのは1度や2度ではなかった。

それで、やってみてどういう意味があるのかということを考えてみる。活字のほとんどはノイズみたいなもので、必要ないから取り入れない、そういう感じに慣れる、のかなと考えた。それもある。欲しくなったとしても、なくたって困らない。なきゃないで過ごすことができるのだとういうことは、当たり前ではあるが、この身体がそうできるのだと知った、という意味はある。

しかしもっと大きな意味があった。自分の感覚に気がつく。自分は思っていたよりも活字を渇望しているし、取り入れるように手が勝手に動いてしまっているということ。なぜかと考える。どういうときにどうして手が動くのかと考えてみる。安定を欲しているのかもしれない。居場所なのかやり場所なのか、受けたからやる、をするために受けようとしているように見えた。

仕事中にも思う。「このWebストレージにあります」と言われてURLをクリックする。画面はログインを要求するから、これに応じるのだけど、ログイン後のトップページを見てしまっているから、なぜこのページを見ているのかということが頭から飛ぶ。いや、飛ぶというか、もともとないのだ。URLをクリックして、目的のファイルを目にすることを期待しているから、何をするのかを頭に置いていない。目的のファイルを目にすれば次何をするのかは想起することができて、手を動かせる。そういう情報の落とし方、省き方を、結構やっているのだと気がつく。

それで、たとえば、気がついたらTwitterを見てしまっているなどというのは、反射的な身の振り方をし過ぎてしまっていて、それはあまりにも不自由なんだろうなと思う。居場所とかやり場所とかって言葉を選んだのはそういう訳で、どこかに身を置くって姿勢になってるんでしょ。それはやっぱり自由なことではないよね。そんなことは自分で決めたいものだ。

ずっとやりたかったことを、やりなさい。

ずっとやりたかったことを、やりなさい。