目次
はじめに
データベーススペシャリストの過去問(2021年秋午後Iの問1)を例に、
ドメイン駆動設計でCQRSのサンプルプログラムとテストコードを
作成したので(Java + Springで作成)、
サンプルコードの紹介と、
僕のCQRSに対する解釈などについて、
本記事にまとめました。
>>モデリング対象(データベーススペシャリスト2021秋午後I問1)
ドメイン駆動設計の練習モデリング編についてはこちらにまとめています。

本記事では、
松岡さんの「サンプルコード&FAQ」、「モデリング/実装ガイド」を参考にさせて頂きました。
サンプルプログラムの作成及びテストコードの作成は本をなぞった形になります。
(その点お含みおきください)
また、
ドメイン駆動設計でモデリング〜コーディング〜テストコード作成
までのまとめ記事を作ったので興味がある方は是非みてください。

CQRSとは??使い所やメリットデメリットは??
CQRSは参照と更新でモデルを分割するアーキテクチャ。
複数集約にまたがる参照を行う際、
DDDではこれらの問題がある。
- 複数集約から戻り値の型への詰め替えがごちゃごちゃして読みにくい
- 余計な値取得によるパフォーマンス劣化
- 複数集約にまたがる条件でのページングできない
そこで、更新モデル(ドメインオブジェクトや値オブジェクト)とは別に、
参照のユースケース専用に参照モデルを用意することで、
データ取得がシンプルになったり、
クエリのパフォーマンスを改善できたり、
複数集約にまたがる条件でのページングができたりする。
本ではこのように説明されていました。
自分の理解を絵にするとこんな感じ。
CQRSを導入したサンプルコードとテストコード
サンプルコードを作ってみたので紹介します。
お題は
ユーザを指定してユーザ情報とそのユーザの支払い情報リストをセットで取得
という想定で作りました。(支払、ユーザの集約跨ぎで参照のイメージ)
クエリサービスのサンプルコード
ユースケース層にインタフェースを作成しました。
インフラ層に具体的なDB操作を実装しました。
参照用モデルは1ユースケースに特化するのが基本で、
ドメイン知識を持たないのでユースケース層に配置するそうです。
DBの具体的な操作に関しては、リポジトリと同じくインフラ層に閉じ込めます。
クエリサービスのテストコード
自分はインフラ層のテストコードを書きました。
(が、後で本を読むとユースケースのテストコードこそ書くべきだったぽいです、、、)
CQRSを導入したサンプルコードを作成してみた感想や気付き
DDDを導入すると、
性能が破綻するだろうな・・・
今の性能が全てみたいなシステムは導入すべきではないな。
と以前は感じていたのですが、
DDDでも性能対策できる仕掛けを作れる。
ということが分かってよりDDDの導入のハードルが自分の中で下がりました。
一方で、
なんでもかんでも
参照系のユースケース用に参照モデルを作りまくったり、
(部分的に必要に応じで導入すればよい)
参照系の複数のユースケース間で無理やり参照モデルを使いまわそうと
最小公倍数的な何でも入るモデルを作るはやめましょう。
ということも本で述べられていましたが、
そうだよなー・・・
CQRSという引き出しができたものの、
使い所は間違いようにしないとなと。。。。