社内でドメイン駆動設計入門の読書会 #13
こんにちは。Nonです。
今回も会社で読書会をしている話をしようと思います。
内容は控えめに、ディスカッションの内容重視で書いていきたいと思います。
より具体的なコードや内容がみたい！という方は購入しましょう！
読んでいる本
読んでいる本はこちらのドメイン駆動設計です。
ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本
以前の記事でも言っていたように、業務でDDDを利用して開発することが多くなったのですが、DDDに精通している人が少ないという問題がありました。
そこで、その精通している人が読書会をしようかと誘ってくださいまして、是非にと参加させていただきました。
進行方法
読書会の進行方法は
- 今回読書の対象にする章を決める。
- 10〜20分間その章を読む
- 読み終わってしまった人は、もう一周読み直すか、次の章に進んでもらう
- その後40分間で、その章に対する疑問や考え方をディスカッションする
- １〜３を毎週定期的に行う
という進行方向となっています。
社内で読書会をするのはこれが初めてなので、進行方法はもっといいのあったら教えて下さい。
今回読んだ内容
- 複雑な条件を表現する「仕様」
- 仕様とは
- 複雑な評価処理を確認する
- 「仕様」による解決
- リポジトリの仕様を避ける
- 仕様とリポジトリを組み合わせる
- お勧めサークルに見る複雑な検索処理
- 仕様による解決法
- 仕様とリポジトリが織りなすパフォーマンス問題
- 複雑なクエリは「リードモデル」で
- まとめ
ディスカッション
今回は評価と参照
今までのドメインは「ユーザーを作成する」とか、「サークルにメンバーを追加する」など、追加、更新、削除。つまりライフサイクル周りに注目するユースケースばかりでしたが、今回はサークル一覧をどう見せるか、どのようにサークル検索するか、に注目していた章でした。
正直な話、プログラミングにおいて「参照」が一番書かれる頻度が高いと（個人的に）思っているので、気になる章ではありました。
ディスカッションにおける最終的な結論
参照はドメイン駆動で設計しなくてよくね？
参照はデータ参照といっても過言では無いくらいです。
多少の加工はありますが、それは果たしてドメインと言えるのかも甚だ疑問です。
例えば登録されている商品の値段を税抜価格から、税込価格へ変換する処理は知識とは呼べそうですが、Entityに書くほどでしょうか？
また、1000円以上の商品を赤文字で表示するという画面側の要望があるときにその振る舞いをEntityに書くべきなのでしょうか？
これに対する結論が「リードモデル」だそうです。
登録 / 更新 / 削除用のドメインオブジェクトとは別に参照用のドメインオブジェクトを作成する言えばいいでしょうか？
少し誤解（語弊）があるかもしれませんが、そのように私は受け取りました。
参照は性能にも密接に関わる
登録件数1億件のデータにアクセスするとき、単純なクエリで一発で取れるなら、プログラムで処理して、時間をかけるより、SQL一発で簡単にとってそのままレスポンスとして返したほうがユーザーのためになるという意見も今回のディスカッションの中で出たくらいです。
CQRSという考えもあるらしいので、全てにおいてドメイン駆動設計で実装する必要はなさそう。というのが、今回の章で言いたい部分の一つだったのかもしれません。
参照を別の設計で駆動させるときのディレクトリ構造
src┓
┣User┓
┃ ┣CreateUser┓
┃ ┣User
┃ ┣UserName
┃ ┣GetUser┓
┃ ┣全く別の設計手法で書かれたコード
...
となりそうです。
少なくとも、私はそのように書いています。
Entityでgetterはできるだけ書きたくない
これが、一貫してこの本に書かれているのですが、この理論で行くと参照系とは相性の悪い（？）手法なのかもしれません。
CQRSについては別でまた記事にしたい
CQRSについては勉強不足なので、また別の機会に。
最後に
実はドメイン駆動設計で組むぞ！って始めたプロジェクトで一番はじめに組んだコードが参照系でした。
かなり苦労したので、別の手法でコーディングするのは納得できています。
CQRSとまでは行きませんが、単純なSELECT処理をして、フロントが欲しい物を多少加工して返しています。これのせいでコードが汚くなるということも無いですし（参照系ですので）、問題ないと思います。
次回はアーキテクチャです。
また記事にしますので、その時はよしなに。
.
