私が理解しているように、CQRSは、読み取りモデルをドメインモデルから分離し、必要なドメインモデルの投影ごとに特定の読み取りモデルを使用することを提唱しています。
使用ポイントから、読み取りモデルの保存方法と取得方法は透過的である必要があります。クエリを発行して、作成方法を気にせずに読み取りモデルを取得します。
多くの例や記事では、読み取りモデルを保存し、ドメインモデルの変更に応じてそれらを再生成するために、個別のテーブルを使用しています。
次の理由により、このアプローチはあまり好きではありません。
- すべての可能な読み取りモデルが頻繁に必要になるわけではありません。
- 要件を変更すると、既存の読み取りモデルが無効になる可能性があるため、すべてを再生成する必要があります。
- 何らかの理由で読み取りモデルに生成時に保存できないプロパティが含まれているが、計算する必要がある場合は、ストアドプロシージャ/関数/ビューを使用する必要があります。
- ドメインモデルの変更時にアプリケーションレベルのキャッシュが使用される場合、読み取りモデルはドメインモデルとは別であるため、古い読み取りモデルをキャッシュから削除する必要があることをすべてのアプリケーションに通知する必要があります。
- 複雑なオブジェクトグラフを完全に非正規化することが不可能または望ましくない場合があるため、特定のドメインエンティティバージョンに対して一貫性のある読み取りモデルを用意する必要があります。つまり、同じトランザクションで生成する必要があります。
- 一部のドメインエンティティには頻繁に変更されるプロパティがありますが、すべての読み取りモデルに含める必要があります。
これに基づいて、クエリサービスを使用することを考えています。
- 頻繁に生成する必要がある、および/またはドメインエンティティの単純な投影である読み取りモデルの場合：それらを格納せずに、データベース内のドメインモデルエンティティにクエリを実行してORMを介して生成します。
- 頻繁に生成する必要がなく、複雑なドメインエンティティプロジェクションである読み取りモデルの場合、それらを生成してデータベーステーブルに格納します。
また、読み取りモデルをblobとして保存することを提案する人もいます。読み取りモデルをblobとして保存する場合の問題は、それらを検索する必要がある場合は、インデックス作成用のプロパティを抽出する必要があり、全文検索が必要な場合でも、全文で理解できる形式で保存する必要があることです。ツール。
ご覧のとおり、基本的には、クエリの実行後にのみ存在し、ドメイン変更イベントに基づいて生成されない読み取りモデルが必要です。このソリューションはCQRSに受け入れられますか？私がCQRSを検討している理由は、キャッシュ可能なビューモデルをユーザーアクション処理から分離することでアプリケーションアーキテクチャを改善し、ユーザーアクション後に非同期更新を行うAJAX対応のWebアプリケーションを用意し、ビジネスロジックをすべて配置することで、ジュニア開発者が保守不可能なコードを生成する余地を減らすためです。その場で、そして私にとってCQRSの不忠実な実装でさえ、正しい方向への良い一歩のように思えます。