問題タブ [cqrs]

したがって、CQSの基本的な概念に慣れています。この概念では、1つのデータベースに書き込み、読み取り元のクエリデータベースを更新するコマンドがあります。

ただし、データを入力するシナリオを検討し、重複を防ぎたいと考えています。

新入社員のデータ入力を例として使用し、応募フォームの山を調べて新入社員の詳細を入力します。

1. トップシートを取ります。
2. UIに従業員名と一意の給与番号を入力します。
3. 送信。
4. 「完成した山」に紙を入れます。
5. 繰り返す。

たとえば、ユーザーが気が散って、すでに1つを入力したかどうかを思い出せず、「メッセージ」が完全に戻っていない場合など、ユーザーが同じ給与番号を再度入力できないようにするにはどうすればよいでしょうか。ユーザーが検索するクエリデータベース？

アプリケーション/ドメインレイヤーでDDDを使用して、イベントソースのCQRS実装に取り​​組んでいます。次のようなオブジェクト モデルがあります。

私のこれまでの DDD の理解では、次の 2 つの理由から、Person と Booking の両方が別個の集約ルートです。

1. ビジネス コンポーネントが Booking オブジェクトをデータベースから個別にプルする場合があります。(つまり、リリースされた人は、誤った情報のために変更された以前の予約を持っています)。
2. Booking を更新する必要があるときはいつでも、Person と Booking の間でロックの競合があってはなりません。

もう 1 つのビジネス要件は、一度に 2 回以上、Person に対して予約が発生しないことです。このため、(CQRS を使用し、最終的に一貫性のある読み取りデータベースを使用するため) 潜在的に不整合が発生する可能性があるため、読み取り側でクエリ データベースをクエリすることを懸念しています。

集約ルートは、オブジェクトの ID によってイベント ソースのバッキング ストアにクエリを実行できるようにする必要があります (必要に応じて遅延読み込みします)。より理にかなった実装の他の手段はありますか?

CQRS を読むと、電子メール通知について多くの話があります。どこからデータを取得すればよいのか疑問に思っています。あるユーザーが他のユーザーをイベントに招待するシナリオを想像してみてください。イベントに招待されたことをユーザーに通知するために、ユーザーに電子メールが送信されます。

具体的な手順は次のようになります。

1. CreateEvent招待するユーザーのコレクションが関連付けられたコマンドが、サーバーによって受信されます。
2. 新しいMeeting集計が作成され、InviteUser招待されるユーザーごとにメソッドが呼び出されます。
3. ユーザーがイベントに招待されるたびに、ドメイン イベントUserWasInvitedToEventが発生します。
4. 電子メール通知送信者がドメイン イベントを取得し、通知電子メールを送信します。

私の質問は次のとおりです。電子メールに含める情報はどこで入手できますか?

イベントの説明とユーザー名を含めたいとします。これは CQRS なので、私のドメイン モデルでは取得できません。ドメイン オブジェクトのすべてのプロパティは非公開です。次に、読み取り側にクエリを実行する必要がありますか? それとも、電子メール通知を完全に別のサービスに移動するのでしょうか?

Facility集約ルートのリストを含むかなり単純なドメイン モデルがあります。ドメインから発生したイベントを処理するために CQRS とイベント バスを使用している場合、セットの検証をどのように処理できますか? たとえば、次の要件があるとします。

1. Facilityには固有の名前が必要です。

クエリ側で最終的に整合性のあるデータベースを使用しているため、イベント プロセッサがイベントを処理する時点で、データベース内のデータが正確であるとは限りません。

たとえばFacilityCreatedEvent、クエリ データベースのイベント処理キューで、処理されてデータベースに書き込まれるのを待機しています。新規CreateFacilityCommandが処理されるドメインに送信されます。ドメイン サービスは読み取りデータベースにクエリを実行して、その名前で既に登録されている他の があるかどうかを確認しますが、まだ処理されておらず、ストアに書き込まれていないFacilityため、false を返します。CreateNewFacilityEvent新しいものCreateFacilityCommandは成功しFacilityCreatedEvent、イベント プロセッサがそれをデータベースに書き込もうとしてFacility、その名前の別のものが既に存在することを発見すると爆発する別のものをスローします。

CQRS（および一般的にはDDD）に頭を悩ませようとすると、2つのイベントが異なるアグリゲートで発生する状況に遭遇しましたが、それらの順序にはドメインの意味があります。もしそうなら、それらは非常に接近して発生する可能性があるため、タイムスタンプ（私が見たサンプル実装で使用されている）はそれらを区別できません。つまり、順序にあいまいさがあるため、イベントストアにはドメインの「完全な」表現が含まれていません。イベントが発生した場所。

例として、ドメインはアグリゲートにCustomerCreatedEvent適用されるを起動し、Customer次にアグリゲートでCustomerAssignedToAgentイベントを発生させることができAgentます。CustomerAssignedToAgentイベントがの前に発生した場合は意味がありませんCustomerCreatedEventが、通常、これらの両方が1つの操作の結果として発生する可能性があり、タイムスタンプが実質的に同じになる可能性があります。

だから私は物事をひどくモデリングしているだけですか？さまざまな集合体にまたがる一連のイベントが重要になる状況が発生する可能性はありますか？または、イベントが発生した正確なシーケンスを識別できるように、イベントストアにグローバルシーケンス番号を保持する必要がありますか？

これが状況です。レガシーシステムをサポートするには、ユーザーがログインするたびにテーブルに挿入する必要があります。これは基本的にCRUD操作であるため、リポジトリ/エンティティ/コマンド/イベントを作成することは実際には意味がありません。これは、ビジネスルールとはまったく関係がないためです。CQRSコマンドを作成する唯一の利点は、このデータベース書き込みがそのモデルで非同期に発生する可能性があることです。どちらがより良いルートですか？

• CQRSを使用してから、ストアドプロシージャを呼び出します。そのコマンドを処理するとき？
• コントローラでデータベースを直接呼び出すだけです（私はasp.net mvcを使用しています）

変更を最小限に抑えて、クラウド サーバーまたは専用 (または VPS) サーバーのいずれかに展開できる汎用性の高いアーキテクチャはありますか? 明らかに構成の変更がありますが、アプリの残りの部分は一貫したままにして、1 つの保守可能なコードベースを維持したいと考えています。

アプリは ASP.NET および/または ASP.MVC になります。私の開発環境は VS 2010 です。クラウドは Azure かもしれませんし、そうでないかもしれません。専用またはVPSはWin Server 2008でしょう。おそらく。

一般向けの Web サイトではありません。私が考えている Web アプリは、クライアントごとに個別に展開されます。小規模なクライアントもあれば、Web ではなくローカル イントラネットでアプリを実行することを好むクライアントもあります。他のクライアントは、ブラックボックス ソリューションとしてクラウド アプローチを好む場合があります。アプリは数時間実行される場合もあれば、無期限に実行される場合もあります。クライアントとプロジェクトによって異なります。展開シナリオ以外は、アプリはほぼ同じです。

タグからわかるように、メッセージベースのアーキテクチャがおそらく最も汎用性が高いと思いますが、これについて間違っていることにも慣れています。

一般的なアーキテクチャと特定のソリューションに関するすべての提案と指針を歓迎します。

Command Query Responsibilty Separation に関する Greg Young と Udi Dahan の考えを読んでいて、読んだ内容の多くが心に響きました。私のドメイン (配達を行っている車両を追跡しています) には、1 つ以上のストップを含むルートの概念があります。顧客が Web サービスを呼び出してシステムでこれらを設定できるようにし、ルートと車両の進行状況に関する情報を取得できるようにする必要があります。

以前は、ドメイン クラスに非常によく似た「カットダウン」DTO クラスがあり、顧客は StopDto の配列を使用して RouteDto を作成し、CreateRoute Web メソッドを呼び出して RouteDto を渡していました。彼らが GetRouteDetails メソッドを呼び出してシステムにクエリを実行すると、まったく同じオブジェクトが返されます。CQRS の魅力的な側面の 1 つは、RouteDto には、顧客が照会したいあらゆる種類のプロパティが含まれる可能性があるが、Route を作成するときにビジネス設定がないことです。そのため、CreateRoute「コマンド」を呼び出すときに渡される CreateRouteRequest クラスと、クエリ結果として返される Route DTO クラスを個別に作成します。

しかし、顧客がルートを作成するときに、ルートとストップの詳細を提供してもらう必要があります。私が見たとき、私はどちらかをすることができました...

CreateRouteRequest クラスに、各停留所について提供する必要があるデータを表す「何か」の配列である Stops(s) プロパティを指定しますが、このクラスを何と呼ぶのでしょうか? Route DTO 内の DTO のリストと呼んでいるので、これは Stop ではありませんが、「CreateStopRequest」は好きではありません。また、ここで CRUD の考え方にとらわれていて、マスター/詳細情報の観点から考え、顧客にもそのように考えるよう求めているのではないかと思います。

また

CreateRoute を呼び出してから、AddStopToRoute メソッドを何度も呼び出します。これはもう少し「行動的」に感じますが、ストップを含むルートの作成を単一のアトミック コマンドとして扱う能力を失うことになります。ルートを作成してからストップを追加しようとすると、検証の問題が原因で失敗し、部分的に正しいルートになります。

オプション 1 で使用する "StopCreationData" オブジェクトのリストに適切な名前を付けられないという事実は、何かが欠けているのではないかと考えさせられます。

CQRS は、コマンド クエリ責任分離を意味します。

イベントソースの集約バックエンドを使用して、DDD 原則に基づいて構築された環境で、個別の集約ルート(AR) が互いにどのように通信する必要がありますか?

たとえばFacility、AR の作成を担当するファクトリ メソッドを持つ集約ルート (AR) がありBookingます。はBooking、時間に依存するPersonAR と ARの組み合わせですFacility。APersonは単品でのみ予約可能Facilityです。

BookingDDD では、 inPersonとPersoninへの参照を保持していたでしょうFacility。ただし、イベント ソーシングで使用するイベントを生成する場合、バックエンドからイベントの逆シリアル化を処理しようとすると、法外になると思います。したがって、値オブジェクトベースの一意の ID への参照のみを保持することにしました。ただし、AR のメソッドが別の AR の別のメソッドを呼び出す必要がある場合、これは新しい問題を引き起こします。その状況をどのように処理しますか? ドメイン AR からイベント ソース リポジトリにアクセスしますか?

このシナリオの一般的な使用例は何ですか? 私はこれにすべて間違って近づいていますか？