ドメインドリブンデザインのCQRS実装におけるコマンド/クエリのアプリケーションサービスが分離されていますか？

Question

ドメインドリブンデザインでCQRSを実装する場合は、コマンドインターフェイスとクエリインターフェイスを分離します。

ドメインモデルでは、これにより複雑さが大幅に軽減されます（特にイベントソースを使用する場合）。読者のモデルは書込みモデルとは異なります。つまり、あなたの読み書きのための別のドメインサービスのように見えます。

アプリケーションレベルでは、ドメインの読み取りと書き込みの分離のために別々のアプリケーションサービスが必要ですか？

私はこの問題について悪魔の主唱者を演奏してきました。私の考えは、クライアントにその違いを知ってもらうことを余儀なくされる可能性があるということです。しかし、消費しているWebサービスがどのようにそれを使用するかについて考える。一般的に、それは読書のための取得要求を発行し、それが既に知っていることを意味する書面のために投稿します。

私は、よりクリーンなアプリケーションサービスが得られることがわかります。

Answer 1

実際の値は、正しく分離された読み取りとドメインモデルです。彼らは根本的に異なることをします。そして、しばしば非常に異なる形をしています。読まれたモデルが、例えば異なるドメインオブジェクトからのデータのアマルガムを含むことは完全に可能です。

アプリケーションの使用方法とアプリケーション内での機能の仕組みについて考えるとき、分離の必要性を認識することができます。ここでの典型的な例は、典型的なアプリケーションの読み込みと比較した書き込みの回数を考慮することです。読み込み量は書き込み量を大幅に上回ります。違いを維持することで、それぞれの面を最適化してそれぞれの役割を果たすことができます。

「ポスト」は、読み取りモデルを含む可能性のあるビューモデルではなく、コマンドを構成することに注意してください。 CQRSアプローチを使用する場合は、クエリや投稿のやり方を変更する必要があります。実際には、単にビュー・モデルを前後にサーバーに反映するのではなく、はるかに記述的な言語を実現できます。

興味があれば、私は典型的なCQRSアーキテクチャの概要を概説したブログ記事を持っています。あなたはここにそれを見つけることができます：A step by step overview of a typical CQRS application。あなたはそれが有用であることを願っています。

最終ポイント。私たちは新しい機能を追加する過程にあり、分離が非常に有用であることを発見しました。一方の側への変更は、他の側への変更は、同じように他の側に影響を与えません。