問題タブ [cqrs]

私のチームは、マルチテナンシーを必要とするグリーンフィールドアプリケーションの実装を開始しています。私は、特に分散クラウドベースのインフラストラクチャで、単純なスケーラビリティのパターンについて多くの研究を行ってきました。CQRSは流行語のようです（これまでのところ、「CrackforArchitectureAddicts」と呼ばれています。これは非常に面白いと思います。 ）。利点と落とし穴はさておき、本番アプリでこのアイデアを広範に（またはまったく）使用し、実際のガイダンスを提供できるGregYoung以外の人を見つけるのは非常に困難です。

ここに私の質問があります。1。CQRSアーキテクチャは、一般的なマルチテナントアプリケーションに対応していますか、それとも大規模な内部エンタープライズアプリケーションに適していますか。2.このような状況での使用を推奨する場合は、アプローチ、特に早い段階で正しく理解するための事項、および有機的に進化させる必要のある側面について、トレンチからのガイダンスを提供できますか。3.誰かが試してみて、それが難しすぎるか、メリットを実現できなかった場合、またはそれに対して強い議論がある場合（そして、CRUDと階層型デザインに固執することをお勧めします）、それらの経験についても知りたいと思います。

参考までに、アプリケーションは.NETで記述され、フロントエンドは最初はWebベース（ASP.NET MVC）であり、モバイルクライアントやシッククライアントに拡張される可能性があります。同時実行性、トランザクションアクティビティ、およびデータ量はすべて、アプリケーションの存続期間を通じて比較的低いままであると予想されます（大量の金融アプリなどと比較して）。インフラストラクチャについては、Azureの使用を計画しています。

最近いくつかのGregYoungビデオを見ていて、ドメインオブジェクトのセッターに対して否定的な態度がある理由を理解しようとしています。ドメインオブジェクトは、DDDのロジックで「重い」はずだと思いました。悪い例の良い例がオンラインにあり、それを修正する方法はありますか？どんな例や説明も良いです。これは、CQRS方式で保存されたイベントにのみ適用されますか、それともすべてのDDDに適用されますか？

私は CQRS を読んでいて、多くの原則が価値があることを発見しました。しかし、私には 1 つの大きな論点があります。多くの人が、読み取りモデルのクエリをビュー モデルの dto に直接マップすることについて話します。ここまでは順調ですね。しかし、私がよく耳にする「ビューごとに 1 つのテーブルまたは 1 つの選択」という言葉はどこから来ているのでしょうか。確かに、一部の画面は 1-1 を非常に簡単にマッピングします。しかし、ドロップダウンリストやウィジェットなどの参照データなど、複数の選択を伴う複雑な画面で日常的に作業しています...

複数の選択が必要なビューが簡単にわかりました。

ビューがシンプルでフラットな完璧な世界のシナリオで作業する以外に、どうすればこれを回避できますか?

私はCQRSを見てきましたが、Webアプリケーションなどでコマンドの結果を表示することに関しては制限があることがわかりました。

CQRS を使用すると、ビュー全体またはその一部を更新して (2 番目の要求を使用して) 変更を確認する必要があるように思えます。これは、元のコマンド要求が将来処理されるイベントのみを格納するためです。

Web アプリケーションで、コマンド リクエストが作成したイベントの結果をブラウザに返すことは可能ですか?

現在CQRSを研究していますが、いくつかのソースコード（GregYoungのSimpleCQRSとMarkNihjofの）が表示されます。私はまだコマンドとドメインイベントと混同しています。ドメインイベントハンドラーで「データベースを書き込む」ために、常にドメインを永続化する必要がありますか？コマンドハンドラーで（通常はドメインリポジトリを介して）ドメインをデータベースに保存するコードを呼び出してから、ドメインイベントハンドラーに他のもの（読み取りモデルの更新や電子メール通知などの他のサービスの実行など）を処理させるのは一般的ですか？ありがとう。

私は最近、開始しようとしているグリーン フィールド プロジェクトの CQRS と DDD の調査を開始しました。Udi Dahan、Greg Young、Mark Nijhof などから多くの資料を学びました。これらは非常に役に立ち、概念をよく理解していると思います。しかし、これらを自分のドメインにどのように適用できるかについては、まだいくつかの疑問があります。

私のシステムは基本的に複雑なルール エンジンであり、特定の製品の最終価格はルールによって決定されます。製品の定義とルールは、管理者によってシステムに入力されます。ルールは、 「購入の目的」(再販、貸し出し)などの事前定義されたセットの値、またはAgeなどの自由形式の値を持つことができる事前定義されたプロパティのセットを使用して、管理者によって設計されます。

各製品には基本価格があり、ルールが適用される場合、基本的に基本価格に追加または削除されます。

非常に単純なサンプル ルールは次のようになります。

製品 X の場合、IF (購入目的 = 転売および年齢 > 25) の場合、基本価格に 25 ドルを追加します。

したがって、システムを使用するユーザーには 2 種類あります。管理者は、製品、ルール、および基本価格を定義します。what-if UI を介して入力したシナリオに基づいて価格を照会する他のユーザー。

ここでの私の混乱は次のとおりです。シナリオを実行してもドメインの状態はまったく変化しません。他の外部システム/人はシナリオ実行の結果に興味を持っていませんが、実行中のユーザー自身-価格の結果を返します特定のシナリオに適用可能なルールを実行した後の計算。たとえば、ユーザーが製品 Xを選択し、 (購入目的 = 再販および年齢 = 40)などの特定のシナリオの価格を照会する場合があります。. 繰り返しますが、この操作はドメインの状態をまったく変更しないので、クエリだと思います。しかし、最終的な価格を計算するためにシナリオ上で動作するルール エンジンがあり、実行されているドメイン ロジックとして分類できると思います。では、このロジックはどこに属しているのでしょうか。これは、読み取りモデルから離れて機能するクエリですか、それともドメイン モデルで実行する必要があるコマンドのシナリオを実行していますか? 繰り返しますが、ドメイン層はこれらのルールの場所のように感じますが、シナリオ実行の結果をユーザーに渡すにはどうすればよいでしょうか (このように考えるクエリのように感じます)。それとも、CQRS はこの特定の問題に対する適切なソリューションではないでしょうか?

コマンド、ドメイン モデル、ドメイン イベント、モデル DTO の読み取りなどのコンポーネントを備えた、CQRS にヒントを得たアーキテクチャがあるとします。
もちろん、ドメイン モデルで値オブジェクトを使用できます。私の質問は、それらが以下でも使用されるべきかということです:

1. コマンド
2. イベント
3. DTO

上記のコンポーネントで値オブジェクト (VO) が使用されている例は見たことがありません。代わりに、プリミティブ型が使用されます。単純化した例にすぎないのかもしれません。結局のところ、DDD での VO の使用についての私の理解は、VO がアプリケーション全体の接着剤として機能するということです。

私の動機：

コマンド。
ユーザーが住所フィールドを含むフォームを送信したとします。この概念を表す Address Value Object があります。クライアントでコマンドを構築するときは、とにかくユーザー入力を検証する必要があり、整形式であれば、すぐに Address オブジェクトを作成して Command を初期化できます。Address オブジェクトの作成をコマンド ハンドラーに委任する必要はないと思います。

ドメイン イベント。
ドメイン モデルはすでに値オブジェクトの観点から動作しているため、イベントをプリミティブ型に変換する代わりに VO を使用して発行することで、マッピング コードを回避できます。この場合、VOを使用しても問題ないと確信しています。

DTO。
クエリ側の DTO に値オブジェクトを含めることができれば、柔軟性がいくらか向上します。たとえば、Money オブジェクトがある場合、それを EUR で表示するか USD で表示するかを選択できます。読み取りモデルを変更する必要はありません。

CQRS を実装するためのアドバイスの一部が、データベース (またはおそらく LINQ ベースの ORM) に対して直接 ADO.NET クエリを実行するなど、かなり金属に近いクエリの実装を提唱していることを考えると、試して単体テストを行うのは間違いですか?彼ら？

本当に必要なのだろうか？

この問題に関する私の考え：

1. モック可能な「Thin Read Layer」を提供するための追加のアーキテクチャの複雑さは、アーキテクチャの儀式を最小限に抑えるというアドバイスの性質とは正反対のようです。
2. ユーザーが作成する可能性のあるクエリのあらゆる角度を効果的にカバーするための単体テストの数は恐ろしいものです。

具体的には、ASP.NET MVC アプリケーションで CQRS を試していますが、コントローラー アクション メソッドの単体テストを行うか、代わりにドメイン モデルをテストするかを考えています。

よろしくお願いします。

イベントを強調するアーキテクチャのコマンドとイベントの違いは何ですか？私が見ることができる唯一の違いは、コマンドは通常、システム外のアクターによってソース/呼び出されるのに対し、イベントはシステム内のハンドラーやその他のコードによってソースされるように見えることです。しかし、私が見た多くのサンプルアプリケーションでは、それらは異なる（しかし機能的に類似した）インターフェースを持っています。

合理的な単体テストのセットを使用した、エンドツーエンドの CQRS の詳細な例を探しています。

また、誰かがいくつかの CQRS スクリーンキャストも知っていれば、非常に便利です。

私はすでにこれらの例を知っています

• CQRS情報
• 超シンプルな CQRS