Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
682
Help us understand the problem. What are the problem?

More than 5 years have passed since last update.

Organization

DDDで設計するならCQRSの利用を検討すべき

タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。

CQRS+DDD

CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」(副作用あり)と「クエリ」(副作用なし)で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。

  • 一貫性: 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし
  • ストレージ: 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的
  • スケーラビリティ: 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい

なので分けちゃうわけですが、

  • コマンド側
    • 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍
  • クエリ側
    • 複雑なビジネスロジックがないので、ドメイン層はスキップ

クエリ機能についてはDDDを省略することで、柔軟でスケーラビリティの高いクエリ機能を提供しつつ、Repositoryの肥大化を防いで、より重要なドメイン領域の設計に集中することが出来ます。

詳しくはGreg Youngによるオリジナルの文書を参照してください。Sipadan2003さんが日本語にも翻訳してくれています。また、Implementing Domain-Driven Designにも詳しいCQRSの説明があります。

なお、CQRS には必ず Event Sourcing の話がついて回りますが、Event Sourcing なしでもCQRSを利用することは出来ます。

DDD+CQRSのサンプル

最後に

ある程度大きなシステムでないと、DDDのオーバーヘッドはペイしないです。とはいえ、今後のサービスの成長を見越してDDDで設計したい場合が多々あると思うのですが、そのような場合の初期の仕掛けとしてCQRSを導入しておくのは、わりとありかなと思います。あと、DDDと言うと Layered Architecture が有名ですが、ドメイン層を依存関係の中心に置いた Hexagonal Architecture も使いやすいです。

なお、ここまで書いておきながら、CQRSの実践投入はまだやったことがないのであしからず。 少し実践しましたが、やはりクエリの実装が楽になりました。

ドメイン駆動開発シリーズ

追記

"Implementing Domain Driven Design" の日本語訳が出版されましたね。

ドメイン駆動設計を検討しているなら、必携の書です。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
682
Help us understand the problem. What are the problem?