(設計の 1 つの側面として) CQS を使用して新しいプロジェクトを開始しますが、CQRS + イベント ソーシング、イベント ストリーミング、または履歴モデリングは使用しません。少数のデータ セットを使用する多数のユーザーがいる (そしてユーザーをブロックしたくない) 状況に遭遇した場合は、イベント ソーシングを実装します。これが意味すること (少なくとも私にとって) は、コマンドをクエリから分離すること (関心の分離) から始めることだけです。
コマンド側には EF ORM と実際のスキーマを使用しています。クエリ側では、(私が読んでいるものから) ビューのみを使用するのが最善ですが、この意見は、ORM を使用する (または使用しない)、および/またはレポ、または ADO.NET + ストアド プロシージャを排除しないと思います。など、DBからこれらのビューにアクセスする方法として（私は思う）。
これは、私が考えていることを大まかに説明するために作成した図です（決して包括的ではありません）。
私の質問：
パート 1: データベースから (ビュー) を使用し、ViewModel (DTO) を使用してクライアントに何らかの状態の新しいビューを提供します (コマンド側への呼び出し後)。
パート 2: タスク ベースの Web UI を変更し、UI の基礎となる ViewModel を変更した後、ViewModel がコマンド側のエンティティ (ドメイン モデル) から完全に分離されている場合、これからコマンドを発行するにはどうすればよいですか? . これらの ViewModel (DTO) は、エンティティとはまったく異なる "形状" である可能性があります。
更新：
明確にするために、私は非同期を使用するつもりはなく、トランザクションは開始するのにプラスです。これはコマンドとクエリの分離のみです（コマンド側が「無効」のみを返す完全なCQRSではありません）-私は探していますここで非常に基本。また、これまで読んだことから、DDD と境界コンテキストは CQRS と密接に関連しているように見えます。この時点で、境界コンテキストとともに DDD または集約ルートを実際に使用した経験はありません。この方法論/パターンに取り組むための現実的かつ差し迫った必要性。現時点では、コマンド側に EF/Migrations を使用する予定のようですが、クエリ側で何を使用するかはまだ決めていません (ADO.NET を検討中です)。
私の場合、コマンド側はオブジェクトを返します。たとえば、データベースで生成された CustomerId を持つ新しい Customer です。コマンドとクエリの両方に 1 つのデータベースを使用し、クエリからモデルを返すために DB にビルドされたビューを使用したいと考えています (つまり、ほとんどの場合、クエリをビューに "マップ" したいと考えています)。 . 私が知らないのは、クエリ側を使用してコマンド側のデータを返す場合、オブジェクトを返す必要がある場合にコマンドがどのように見えるかです。MVC の場合、オブジェクトを ViewModel に変換する Automapper を組み込んでみます。