問題タブ [dddd]

CQRS / DDDとの古典的な多対多の関係をどのようにモデル化するのですか？

DDDとCQRSの両方の実装とソリューションはドメイン固有である傾向があることを私は知っているので、この質問に対する一般的な答えを思い付くのは難しいかもしれません。

ただし、 BookとAuthorの間に馴染みのある関係があると仮定しましょう。これは古典的な多対多の関係です。

私には、BookとAuthorがそれぞれ独自のAggregateRootに属する2つの異なるエンティティであることが最も自然に思えます。したがって、それらの間の多対多の関係を明示的にモデル化することは、進むべき道ではありません。

AddBookCommandをどのようにモデル化しますか？ライブラリに本を追加できるようにしたいのですが、特定の著者がこの本を書いたとどういうわけか述べています。このような関係をどのようにモデル化（および永続化）しますか？

BookもAuthorもValueObjectsの良い候補ではないようです...

私はまだCQRSスタイルのアーキテクチャに関連する基本的な（そして解決された）問題に苦労しています：

集約ルートのセットに依存するビジネスルールをどのように実装しますか？

例として、予約アプリケーションを取り上げます。コンサートのチケット、映画の座席、レストランのテーブルを予約できる場合があります。いずれの場合も、販売される「アイテム」の数は限られています。

イベントや場所がとても人気があると想像してみましょう。新しいイベントや時間帯の販売が開始されると、予約は非常に迅速に到着し始めます。おそらく1秒あたりの数が多くなります。

クエリ側では、大規模な拡張が可能であり、予約はキューに入れられ、自律コンポーネントによって非同期的に処理されます。最初は、予約コマンドをキューから削除するときに受け入れますが、ある時点で、残りのコマンドを拒否し始める必要があります。

限界に達したとき、どうやって知ることができますか？

予約コマンドごとに、ある種の店舗に問い合わせて、リクエストに対応できるかどうかを判断する必要があります。これは、その時点ですでに受け取った予約の数を知る必要があることを意味します。

ただし、ドメインストアがWindows Azureテーブルストレージなどの非リレーショナルデータストアである場合、SELECT COUNT(*) FROM ...

1つのオプションは、次のように、現在のカウントを追跡するだけの個別の集約ルートを保持することです。

• AR：予約（誰？何人？）
• AR：イベント/タイムスロット/日付（集計数）

2番目の集約ルートは最初の集約ルートの非正規化された集約ですが、基盤となるデータストアがトランザクションをサポートしていない場合、大量のシナリオでこれらが同期しなくなる可能性が非常に高くなります（これが私たちが試みていることです）そもそもアドレス）。

考えられる解決策の1つは、予約コマンドの処理をシリアル化して、一度に1つだけが処理されるようにすることですが、これはスケーラビリティ（および冗長性）の目標に反します。

このようなシナリオは、標準の「在庫切れ」シナリオを思い出させますが、違いは、予約をバックオーダーにうまく入れることができないことです。イベントが完売すると完売するため、補償措置がどうなるかわかりません。

そのようなシナリオをどのように処理しますか？

リポジトリを使用してデータベースと通信するシステムがあります。リモートサービスの正しい定義は？またはより良い、

[...] は外部 Web サービス用であるため、リポジトリはデータベース用です。

ServiceAgents について多くの場所で見つけましたが、これが正しい定義かどうかはわかりません。

Microsoftテクノロジ（すべてのコンポーネントを完全に制御できる）を使用してDDD（WCFを使用しているためDDDDの方が優れている）でn層アプリケーションを開発する場合、最適な選択はSTEとPOCOのようです（この最後の1つはDTOの使用を強制します） 。それは正しい？あなたの意見では、STEとDTOを必要な場所で使用することは理にかなっていますか？

ありがとう。

私は CQRS を使い始めたばかりで、フォームで Command オブジェクトをモデルとして使用するのが最も理にかなっていると考えました。DataAnnotations を使用したコマンドのクライアント側検証の一部を利用できます。クライアント側検証により、かなりクリーンになります...

私の質問...これは何か問題を引き起こしますか? コマンドにデフォルトのコンストラクターがない場合、このプロセスは不可能になりますか? コンストラクターが集約 ID を挿入できる独自の CommandModelBinder を作成する必要がありますか?

あなたの考え、私はこのテクニックをどこにも見つけることができません。

私は DDD アプリケーションの開発にかなりの自信を持っていますが、2 つのアプリケーションを相互に統合する際に、引き続き問題を引き起こしている領域の 1 つです。このテーマに関する有用な本やリソースを見つけるのに苦労しています。Patterns of EAI などの本は、メッセージング パターンとメッセージ構築について深く掘り下げていますが、これらのパターンを利用するシステムを構築する方法については実際には説明していません。

私は高低を検索しましたが、2 つのシステムを統合する方法を示すサンプル アプリケーションはないと確信しています。非同期メッセージングの概念は理解していますが、それを適用する良い例が見つかりません。

SOA に関するリソースは、実装方法を示すことなく同じ概念を繰り返し繰り返しているように見えます。

私が答えるのに苦労している種類の質問は次のとおりです。

1. 各アプリケーションは、データの独自のコピーを持つ必要がありますか? たとえば、組織内のすべてのアプリケーションは、メッセージの受信時に更新するクライアントの独自のリストを持つ必要がありますか?

2. DDD スタックのどの時点でメッセージが渡されますか? それらはドメイン イベントの結果ですか?

3. 非同期メッセージングと WCF を組み合わせることができますか、それとも選択する必要がありますか? 要求/応答とパブリッシュ/サブスクライブのメッセージングに WCF を使用しますか?

4. ある DDD アプリケーションが別のアプリケーションのサービスをどのように利用するか? ポイント 1 で述べたように、1 つの DDD アプリケーションがそのアプリケーション サービスを介して別のシステムにそのデータをクエリする必要がありますか、それともデータの独自のローカル コピーを既に持っている必要がありますか?

5. どうやら、2 つのシステム間で取引を行うことはできません。どうすればこれを回避できますか?

私が混乱しているように聞こえるとしたら、それは私が混乱しているからです。上記の質問に対する回答を探しているわけではありません。これと同様の質問に回答するリソースの方向を示しているだけです。

そのタイトルを短くする方法がわかりませんでした。

私は基本的に、CQRS（http://en.wikipedia.org/wiki/Command-query_separation）の概念と関連する概念に頭を悩ませようとしています。

CQRSは必ずしもメッセージングとイベントソーシングを組み込んでいるわけではありませんが、それは良い組み合わせのようです（これらの概念を組み合わせた多くの例/ブログ投稿で見られるように）

何かの状態変化のユースケース（たとえば、SOに関する質問を更新する場合）を考えると、次のフローは正しいと思いますか（ベストプラクティスのように）？

• システムは、いくつかの小さなコマンドに分割される可能性のある集約UpdateQuestionCommandを発行します。QuestionAggregateRootを対象とするUpdateQuestionと、User Aggregate Rootを対象とするUpdateUserAction（ポイントなどをカウントするため）です。これらは、ポイントツーポイントメッセージングを使用して非同期に送信されます。

• 集約ルートはそれぞれの役割を果たし、すべてがうまくいけば、イベントQuestionUpdatedとUserActionUpdatedをそれぞれ起動します。これらのイベントには、イベントストアにアウトソーシングされた状態が含まれます。

• これらのイベントは、ブロードキャスト用のpub/subキューにも配置されます。すべてのサブスクライバー（読み取りビューを作成する1つまたは複数のプロジェクター）は、これらのイベントを自由にサブスクライブできます。

一般的な質問：コマンドがポイントツーポイントで通信される（つまり、受信者が既知である）のに対し、イベントがブロードキャストされる（つまり、受信者が不明である）ことは、実際にベストプラクティスですか？

上記を想定すると、コマンドをポイントツーポイントではなくpub / subを介してブロードキャストできるようにすることの長所/短所は何でしょうか？

例：佐賀（http://blog.jonathanoliver.com/2010/09/cqrs-sagas-with-event-sourcing-part-i-of-ii/）の使用中にコマンドをブロードキャストすると、問題が発生する可能性があります。佐賀は、どの集合ルートが最初に参加するかを知らないため、集合ルートの1つに障害が発生した場合に佐賀が果たす必要のある仲介の役割が妨げられます。

一方で、コマンドのブロードキャストが許可される場合の利点（柔軟性）がわかります。

私の頭をきれいにするのにどんな助けでも大歓迎です。

イベント ドリブン アーキテクチャを始めたばかりで、コマンドとイベントの命名規則を知りたいです。コマンドは DoSomething の形式である必要があり、イベントは SomethingHappened の形式である必要があります。明確にする必要があるのは、コマンドに「コマンド」という単語を追加し、イベントに「イベント」という単語を追加する必要があるかどうかです。また、コミュニティが好む慣習の背後にある理論的根拠を知りたいです。ありがとう！

私がDDDで読んだことはすべて、集合体内の状態が強く一貫している必要があることを意味します。

これは、冗長性が必要な場合は、強一貫性のあるレプリケーション（2PC、3PC、Paxosなど）のみを使用できることを意味します。

マルチマスターやマスタースレーブのような結果整合性のあるレプリケーションを使用できますか？それらを使用した場合、DDD用語でまだ「集計」されているものはありますか？これは一般的なことですか？