問題タブ [command-query-separation]

• CQS の原則 ( https://en.wikipedia.org/wiki/Command%E2%80%93query_separation ) では、コマンドは void を返す必要があると規定されています。
• 非同期メソッドの推奨事項は、決して void ( https://msdn.microsoft.com/en-us/magazine/jj991977.aspx ) を返さず、代わりに Task を返すことです。

では、非同期コマンドを作成すると、必然的に CQS の原則が破られるのでしょうか?

私はCQRSパターンとは何かを学んでいて、 CQSパターンもあると知りました。

検索しようとすると、CQRSに関する多くの図と情報が見つかりましたが、 CQSについてはあまり見つかりませんでした。

CQRSパターンのポイント

CQRS には、書き込むモデル (コマンド モデル) と読み取るモデル (クエリ モデル) が 1 つずつあり、これらは完全に分離されています。

CQS は CQRS とどう違うのですか?

( ) パターンに準拠した // アプリケーションをJava開発していSpringます。HibernateCQSQuery Command Separation

簡単に言えば：

• ourは、ドメイン モデルで実行する必要がある操作を記述する場合にdomain modelのみ使用されます。Commands
• すべての読み取り操作は、QueryServiceをバイパスするによって実行されるため、ユース ケース ベースで各クエリをdomain model( を使用して) 最適化できます。projection

MySQLドメイン モデルは、 を使用してデータベースに マップされますHibernate。

ドメインと永続化モデルの分離について、長期にわたる議論があることは知っています。しかし、最近では Hibernate が非常に柔軟になったため、ドメイン モデルを犠牲にする必要がなくなったと確信しています。この方法では、ドメインと永続化モデルの間で 1 対 1 のマッピングが得られません。さらに、すべての DB 関連のものは、レイヤー スーパータイプを使用して抽象化できます。

私の質問:

1. Hibernate Queryで(またはCriteria) プロジェクションを使用する場合QueryService、実際にはプレーン SQL の代わりにドメイン モデルを使用しています。これはパターン違反ではないでしょうか…？CQS
2. でプレーン SQL を使用することを選択できますQueryService。ドメインモデルを使用せずにクエリを構築し、結果を JavaBeans に簡単にバインドできる優れた SQL フレームワークはありますか? 結果は通常グラフであるため、これらをネストされた JavaBean 構造に簡単にバインドできると便利です。

まったく新しいdomain model(およびBounded Context) ' Appointment' 用の新しいアプリケーションを作成しています。CQS新しいドメインには、Hexagonal Architecture(ポートとアダプターを使用して) を組み合わせることにしました。

パッケージ構造は主に次​​のようになります。

私の質問:

1. このパッケージ構造は、私たちが達成しようとしていることに問題ありませんか?

2. インターフェイスを介して他のドメインとの間のすべての通信を確認したいと考えていAppointmentScheduleFacadeます。クロスドメイン通信は、分散されていないため、単純なメソッド呼び出し (RPC または REST なし) として存在します。

   ファサードは主に次のものに委任します。

   • AppointmentScheduleApplicationService.javaモデル修正用
   • AppointmentScheduleQueryService.java他のドメインにデータを渡すため。

この設定は大丈夫ですか？または、他のドメインがApplicationandに直接対応する必要がありQueryServiceますか?

Octet8 つのサンプルを「パッケージ化」してから送信するクラスがあります。新しいサンプルを追加し、すでにいっぱいかどうかをチェックFrameし、Octet.

このOctetクラスは、「まだいっぱいではないため抽出できません」と「すでにいっぱいであるためにサンプルを追加できません」という 2 種類の例外をスローします。そのために、クライアント コードは を呼び出す前に満杯かどうかを確認し、満杯にAddなったらすぐに抽出し、それをリセットする必要があります (正直なところ、非常に不十分なクラス コントラクトです)。

問題は、クライアント クラス (使用している唯一のクラスOctet) がスローされる操作の前に正しくチェックを実行しているように見えても、2 種類のエラーが発生していますが、エラー条件が発生しているにもかかわらずです。さらに悪いことに、デバッガーが壊れたときに値を確認すると、それらは正しいです。つまり、例外がスローされるべきではありません!

CQS を使用してエンティティを更新する方法を理解しようとしています。ユーザーが特定のエンティティのいくつかのプロパティを更新できる UI があるとします。送信時に、バックエンドで更新コマンドが作成されてディスパッチされます。

私がよく理解していない部分は次のとおりです。

1. ディスパッチャーからメッセージを受信した cmd ハンドラーは、DB から既存のエンティティを取得し、受信した在庫アイテムのプロパティをマップして保存しますか? または
2. 既存のアイテムの取得は、cmd msg のディスパッチの前に行われ、そこにアタッチされますか (取得されたエンティティは、次にディスパッチされる cmd にアタッチされます)?

私の理解では、CQS を使用すると、後で (必要に応じて) CQRS に簡単に移行できますか? あれは正しいですか？

その場合、上記 2 の問題は、コマンド/書き込みスキーマとは非常に異なるスキーマからクエリを取得できることです。何か不足していますか？