問題タブ [aggregateroot]

誰かが次のことを明確にしてください。

次のモデルがある場合。

プレゼンテーション --> スライド --> ビデオ

プレゼンテーションを集約ルートとして特定した場合、これは、プレゼンテーションにスライドを追加したい場合は、たとえば、presentation.addslide(slide myslide) などの集約ルートを経由し、追加したい場合は同様の方法で行う必要があることを意味しますか?スライドへのビデオ 私も集約ルートを通過する必要があります。例えば、presentation.addvideotoslide(video myvideo, int slideNumber)???

または、プレゼンテーションと一緒にスライドを使用して、スライドにメソッドを含めることもできますか?たとえば、slide.addvideo(video myvideo)???

ありがとう

集計ルートで計算されたプロパティを永続化する必要があります。計算は子エンティティに基づいています。ルートを使用して、ドメイン メソッドを介して子を追加/削除しています。これらのメソッドは、計算プロパティを更新します。

子エンティティは、システムの複数のユーザーが特定のルートに追加できます。たとえば、UserA は子を Root123 に追加でき、UserB も子を Root123 に追加できます。

複数のユーザーが異なるトランザクションで同じルートに子エンティティを追加している可能性がある場合、この計算されたプロパティが正確に保持されるようにするにはどうすればよいですか? 私の特定のケースでは、ルートの別のプロパティによって設定されているように、計算されたプロパティを使用して、制限を超えないようにしています。

問題のより具体的な例を次に示します。

2 人のユーザーがほぼ同時に提案を送信した場合はどうなりますか? UI は、まだ制限に達していないことを確認し、両方のユーザーに提案を送信するための Web ページを表示します。最初のユーザーが送信すると、すべてがうまくいきます。これで、最初のユーザーが 2 番目のユーザーの前に送信する限り、2 番目のユーザーは問題ありません。2 番目のユーザーが送信すると、DB からデータが取得され、制限が正確になります。

これは論点ですか？2 人のユーザーがほぼ同時に送信するまれなケースでは、DB の制約 (ProposalLimit >= ProposalCount) に依存する必要がありますか?

集合ルートの子を直接変更するのではなく、集合ルートのメソッドを介して実行する必要があることを理解しています。例えばorder.SetOrderLineQty(product, qty);

しかし、aggregate-rootの子が抽象的なものである場合はどうなりますか？アグリゲートの一部としてIWheelのリストを含むCarアグリゲートルートがあるとします。アグリゲートルート（ホイールの具体的なタイプについて何も知らない）を介して、ホイールのプロパティをどのように追加/変更しますか？

より現実的な例は次のとおりです。医師は、IMedicalNoteのリスト（MedicalReport集計の一部として）を含むMedicalRerport（集計ルート）を作成できます。IMedicalNoteは基本クラス/インターフェースであり、BloodCheckNote、TemperatureNote、MineralConcentrationNoteなどのいくつかの具体的なサブクラスにサブクラス化されています。

各サブクラスには異なるプロパティがあり、それらはすべて編集可能です。MedicalReport集計には、これらのメモの1つ以上が含まれる場合があります。（各ノートサブクラスには、ユーザーが詳細を入力/更新するための特定のユーザーコントロールがあり、大きなMedicalReport画面の下にパネル/タブとして表示されます）

私の質問は、aggregate-root（MedicalReport）を介してこれらのメモのプロパティを厳密に追加/編集するにはどうすればよいですか？これらのメモのプロパティを直接変更することは許可されていないため、1つの醜いオプションは、集約ルート（MedicalReport）で可能なすべてのメモのプロパティを公開することです。

これらの各メソッドは、内部の子コレクション内のメモ項目を更新（または新しい作成）します。これには2つの明らかな問題があります。

1. 集約ルートで可能なすべてのIMedicalNoteサブクラスの使用可能なすべてのプロパティを事前に定義する必要があります。サブクラスの数は増えることが保証されているため、これは受け入れられません。これは、キャプチャする医療データのタイプによって異なります。これは、そもそも継承の要点です。
2. リスト内に同じノートタイプの複数のインスタンスが存在する可能性があります。report.SetBloodCheckComment(comment)このAPIは失敗します。これは、リスト内の複数のBloodCheckNoteアイテムを許可しているため、リスト内のBloodCheckNoteアイテムを更新するとは言えないためです。

MedicalReportアグリゲート全体が保存に有効かどうか、アグリゲートが変更可能でないかどうか、大まかな楽観的同時実行性チェックなどを制御する必要があるため、aggregate-rootを介してこれらのメモへのすべての対話を維持したいと思います。どうやってやるの？

私たちは新しいプロジェクト (既存のアプリを書き直す) に取り組んでおり、ドメイン モデル / リポジトリの設計で問題が発生しています。

これは、ドメイン モデルの 2 つの重要な部分の (簡略化された) バージョンです。

ご覧のとおり、私はPostの抽象的な概念を持っています。これは、レビュー、ディスカッション、写真、ビデオなどのようなものです。投稿にはコメントを含めることもできます。

また、場所の抽象的な概念もあり、これは明らかに通り、都市、近隣などです。

さて、これは自然に私には 2 つの明確な集合根として見えました。

そこで、2 つのリポジトリを作成しました。1 つはPostRepositoryと呼ばれ、もう1 つはLocationRepositoryと呼ばれます。

これはすべて正常に機能していました。これら 2 つのリポジトリのいずれかを介して、任意のタイプの投稿 (またはコメント) を追加/取得し、任意のタイプの場所を追加/取得できます。

しかし、今は都市の「ランディング ページ」のシナリオにいます (たとえば)。

このページでは、基本的に「この場所のすべての投稿」を表示する必要があります。

それはどのように定義されていますか？まあ、投稿は（オプションで）場所でタグ付けできます。実装の詳細なので、データに深く入り込みたくはありませんが (それは DDD の目的ではないため)、基本的には、場所のシェープ ファイルによって特定の場所にどの投稿が含まれているかを判断するための地理空間インテリジェンスがあります。タグ付けされた投稿の緯度/経度。

しかし、境界を越えずにこの情報を取得するにはどうすればよいでしょうか?

どのリポジトリを使用しますか? 新しいものが必要ですか？

重要な場合 (または好奇心旺盛な場合)、これは SQL Server 2008 データベースと Entity Framework 4.0 を備えた Web アプリケーション (ASP.NET MVC) です。

説明が必要な場合はお知らせください。

編集

現在、ドメイン モデルを取得するために仕様パターンの修正版を使用しています。

たとえば、スコア >= 4 のすべてのレビューを取得する BLL のコードは次のとおりです。

しかし今、次のようなコードが必要です。

問題は、中間結合エンティティ (LocationPost - 多対多であるため) を追加せずに上記のクエリを実行する方法がわからず、それに Post ドメイン モデルに FK を追加することです。

でもそうする事で、私は総計の境界を越えていますね。

プレゼンテーション層がどのように構成されているかが、集約ルートを設計するためのリードになるかどうか疑問に思っていました。

エンティティ ProjectEntity とその関連エンティティ ProjectMemberEntity (1:M) を作成します。

このページは次のように構成されています。

ページ上部は ProjectEntity のフォームです

フォームの下には、ProjectMemberEntity のリストを表示するグリッドがあります。

新しい ProjectMember が追加される場合、ユーザーはこのページに移動し、グリッドのヘッダーにある [新しいメンバーの追加] ボタンをクリックする必要があります。編集と削除も同じように類似しています。

この動作/「ページ構造」が集約ルート(projectentity)のヒントになるかどうか疑問に思っています

私はこれらのエンティティを持っています

• ユーザー
• タスク - すべてのタスクにユーザーを割り当てる必要があります
• プロジェクト - タスクをプロジェクトに割り当てることができますが、必須ではありません。ユーザーをプロジェクト作成者として割り当てる必要があります
• TaskStatus - すべてのタスクにステータスが割り当てられている必要があります

そして、次のように集約ルートを設計しました

集約ルート

• エンティティを持つユーザー:タスク、タスクのステータス
• 計画

私は正しい方向に進んでいますか？

集約ルートの子を直接更新するのがベスト プラクティスですか、それとも集約ルートを介してのみ更新するのがベスト プラクティスですか? たとえば、どちらが優先されますか:

また

この部門のガイダンスをいただければ幸いです。

最初に子エンティティを作成してから集約ルートに渡して追加する方法と、集約ルートでそれらを作成する方法のどちらが優れていますか? 例えば：

または

どちらがより良いアプローチですか? これは純粋に主観的なものだと思いますが、どちらがより多くの長所と短所があるかを確認したいと思います.

私はかなり長い間、そこにある他の投稿を集約ルートに相対的に見てきました。集約ルートを正しい方法で定義する方法がまったくわからないようです。集約ルートが集約ルートではない、またはその逆などの回答を見ました。私は少し混乱しています。問題は、私が頭の中にリレーショナル モデルを持っていることですが、DDD がそのように進まないことはわかっています。

関係モデルから集約ルートを定義する方法はありますか?

たとえば、それぞれがタスク、問題、およびメモを保持するジャーナル エントリを保持するジャーナルがあるとします。

集約ルートをどのように定義しますか? ルートはジャーナルですか? ただし、メモ、問題、およびタスクにアクセスする場合は、問題が発生する可能性があります。それらは、ジャーナルエントリへの参照を保持する集約ルートでもありますか?

わかりにくいので、もう少し詳しく教えていただきたいです。

ありがとう。

私は DDD を見ていて、いくつかの考えがあります。ショッピング サイトには、典型的な注文があります。

支払いは注文に置くのが自然なようです。注文を行うとき、または注文を処理するとき、支払いは注文の一部です。

しかし、後で管理者は支払いを個別に処理したいと考えています。たとえば、管理インターフェイスには、処理する必要がある支払いのリストがあります。

どうすればいいですか？Payments を注文から削除して、独自のルート集計にする必要がありますか?