問題タブ [aggregateroot]

Aggregate rootsとAggregatesの使用方法を理解しようとしていますが、具体的な情報や例が見つかりません。

たとえば、次の3つのエンティティがあります。

1. 調査
2. 質問グループ
3. 質問

質問エンティティは、 SurveyまたはQuestionGroupエンティティなしでは存在できません。すべての質問はQuestionGroupに属しているので、私の理解は

QuestionGroupは、Questionの集約ルートです。

質問グループも調査の一部でないと存在できないため、

調査はQuestionGroupへの集約ルートです

上記はネストされた集約ルートの場合のようです。

Q1。実際にC＃でAggregateルートとAggregateを作成するにはどうすればよいですか？それはコードではどのように見えますか？内部クラスを使用しますか、それともAggregateルートが参照を保持しますか？これに関する良い例は見つかりません。

Q2。さらに一歩進んで、ネストされたAggregateルートをどのようにコーディングしますか？

どうも！

ユーザーがフォームで質問に答えるシステムがあります。このモデルを表すオブジェクトがありますが、DDDの観点からこれらのオブジェクトを整理する方法がよくわかりません。

1. セクションのフォーム（独自のリストがあります）。
2. セクション->（独自のリストがあります）グループ;
3. グループ->（独自のリストがあります）質問;
4. 質問->（独自のサブ質問のリストを持つことができます）質問;
5. 質問->（独自のリストがあります）回答;
6. Answer->（独自のリストがあります）Answer_Details;
7. Answer_Detail->（サブ詳細の独自のリストがある可能性があります）Sub_Answer_Details。

すべてのオブジェクトには15を超えるプロパティがあり、それぞれが親なしでは意味がありません。DDDによると、フォームエンティティは集約ルートであり、他のすべてのオブジェクトは値オブジェクトである必要があると私は信じています。つまり、Formエンティティ専用のリポジトリが必要です。この場合、FormRepositoryは、子オブジェクトのすべての種類のCRUDメソッドで雑然としています。DDDに関して私の推論は正しいですか？非常に大規模な集計になってしまうのは問題ありませんか？そのような表現は、パフォーマンスの問題に簡単につながる可能性があると思います。

この命名の問題の解決策を見つけようとしましたが、Web上のどこにも同様の使用法を見つけることができませんでした。ドメインモデルにデザインフローがあるか、いわゆる「ValueObjects」に適切な名前を使用していない可能性があります。

以下をお読みください。

CQRSパターンのドメイン駆動設計を使用します。以下は、ドメインモデルがどのように設計されたかです。

PS関連はありませんが、参考までに、アプリケーションはASP.NET MVCを使用し、コントローラーはサービスレイヤーと通信します。DTO（データ転送オブジェクト）はMVCコントローラーに渡されますが、これは上の図にはありません。

問題は、「ValueObject」を正しく使用していないことです。Martin Fowlerの定義によると、私たちのValueObjectsはValueObjectの真の表現ではありません。 http://martinfowler.com/bliki/ValueObject.html

たとえば、ValueObjectsにはIDがあります。

これらのValueObjectは、コマンド、AggregateRoots、およびドメインエンティティ間でデータを伝送するだけです。たとえば、AggregateRootは、ドメインエンティティに基づいてValueObjectsを作成し、それらのValueObjectsをコマンドレイヤーに返します。

以下は完全な実装ではありません。相互作用を示すための簡単な例

AggregateRoot拡張メソッド：

AggregateRoot：

指示 ：

これらのいわゆる「ValueObjets」の適切な名前を見つけるのに苦労しています。これらもDTOではないようです。また、サービスレイヤーで使用されるDTOと区別できるようにしたいと考えています。具体的には、これらのタイプのオブジェクト（ValueObjects）に呼び出すことができる適切な名前を知りたいと思います。どんな考えでも大歓迎です。

から：

データが変更されるたびに維持する必要がある一貫性ルールである不変条件には、AGGREGATE のメンバー間の関係が含まれます。AGGREGATES にまたがるルールは、常に最新であるとは限りません。イベント処理、バッチ処理、またはその他の更新メカニズムを通じて、指定された時間内にその他の依存関係を解決できます。ただし、AGGREGATE 内で適用される不変条件は、各トランザクションの完了時に適用されます。

a) これは、複数の集約間の一貫性を維持するように設計されたルールは、これらの集約の 1 つが変更を永続ストレージに保存している時点で強制する必要はなく、後で強制することができると言っていると解釈します。この集約は、永続ストレージとのトランザクションをすでに完了していますか?

b) しかし、一貫性のないデータや破損したデータにつながるため、なぜそのような動作が許容されるのでしょうか?

ありがとうございました

集約ルート内のポリモーフィックな子エンティティを更新する最良の方法を見つけようとしています。参考までに、オブジェクトShippingContainerを格納するルート エンティティがあるとします。、など、Cargoさまざまな種類のCargoオブジェクトがあり、それぞれに固有のプロパティがあります。BigCargoHazardousCargo

私はこの質問を読んでいました: Update an entity inside an aggregate

この質問に対する答えは、ある種の DTO パラメータ オブジェクトを取得ChangeCargoするオブジェクトにメソッドを配置する必要があることを示しているようです。ShippingContainer私の質問は、更新しようとしているオブジェクトがポリモーフィックである場合に、これがまだベスト プラクティスであるかどうか (Cargo オブジェクト タイプをミラーリングする DTO オブジェクトの階層が必要ですか?)、または何か他のことを行う必要があるかどうかです。

まず、私は DDD の初心者であり、「青本」を読む必要があることを認めます。

「Match」タイプの AggregateRoot を持つシステムを構築しています。各試合は「投票」のコレクションを持つことができ、ユーザーが試合に賛成票または反対票を投じると増加する読み取り専用の「VoteCount」プロパティもあります。

多くのユーザーが同時に試合に投票する可能性があるため、投票は試合に追加/削除する必要があり、VoteCount は書き込みロックを含む 1 つのアトミック操作としてインクリメント/デクリメントする必要があります (ロックは DB によって処理されます)。(他のプロセス/コンポーネントから効率的にクエリを実行するには、データベース内の静的な値として VoteCount が必要です。)

厳密な DDD に準拠している場合、この操作を次のようにコーディングするように思えます。

アプリケーション サービスは、投票要求オブジェクトを受け取ります。サービスは、Match リポジトリから Match オブジェクトを取得します。サービスは、Match オブジェクトに対して何らかのメソッドを呼び出して、Vote をコレクションに追加し、VoteCount を更新します。その後、リポジトリはその Match インスタンスを DB に保持します。ただし、このアプローチは、次の 2 つの主な理由から、私のアプリケーションでは実行できません。

バックエンドで MongoDB を使用していますが、この読み取り/書き込み操作をトランザクションにラップして、Match データとそれに関連する Vote および VoteCount のダーティ リードを防ぐことができません。

非常に非効率です。Vote を追加して VoteCount をインクリメントするためだけに、オブジェクト グラフ全体を引き戻しています。これは、リレーショナル データベースよりもドキュメント データベースの方が効率的ですが、まだ不要な読み取り操作を行っています。

問題 1 と 2 は、単一の Vote オブジェクトをリポジトリに送信し、Mongo に対して 1 つのアトミックな更新ステートメントを実行する場合には問題になりません。

この場合、投票は「集計」と見なされ、独自のリポジトリと集計ステータスに値するでしょうか?

私はこれを読みました、そしてそれは私に二度考えさせます...：

「作業単位のパターンは避けてください。集約ルートはトランザクション境界を定義する必要があります。」

ドメイン駆動設計を適用するUOWパターンを避ける必要があるのはなぜですか？

If you follow the repository pattern they... say to create a repository for each root aggregate entity.

That means when I have this model:

customer has orders order has products product has supplier

etc...

That would mean I have 4 repositories which are put into ONE repo. customer is the root entity.

Do I misunderstand here something?

私は最近、既存のデータベース (Oracle) と MVC 4 を使用したプロジェクトを開始しました。すでに多くのコーディングが行われています..しかし、コードには「戦略」はありません..DB -> ORM -> Controller だけです。だから私は、いくつかの DDD 開発テクニックを練習するだけでなく、開発にフレアを追加しようとしています。

いくつかの集約ルートを定義しました。それぞれに、それらの保存と削除 (およびその子) などを処理するリポジトリがあります。これらの集約ルートの 1 つは別の集約ルートへの参照を持ち、「子オブジェクト」を介して処理します。それ。

例：

それは結構です..クライアント集約ルート、注文書集約ルート。

現在、発注書のステータスを変更するサービスのように、いくつかのサービスも登場しており、発注書ARから負担を取り除きます。注文書のステータス)、(おそらく、それは注文書 AR の一部であるべきでしょうか? 些細なことです..)

リポジトリは現在、データベースからのデータを永続化する仕事を行っており、ARをデータで「埋め尽くし」ています。ARがそれを「保存」すると、リポジトリは、保存が必要なものをすべて保存します。Purchase Order Repository はクライアントARによって使用されるため、クライアントはそこに含まれる可能性のあるすべての発注書をロードできます。うまくいけば、正しい軌道に乗っています。

ここで、MVC に入ります。そのため、いくつかの ViewModel も用意しました。これは基本的に、ユーザーに何を送り出す必要があるかについての表示定義です。Automapper は驚くべきものであることが証明されているので、ビュー モデルに「自動マップ」するだけです。頭脳は必要ありません、完璧です..

今、本当に私を悩ませている実装の詳細..

コントローラーは現在、 Client Factory を介して動作しており、これは Client ARを返します。これは、購入注文リストコントローラーが行う必要があるすべてのことを行うことができます。これは、関連する注文書を管理します (注文書の詳細やこの場合のデータ)。

だから今、私はこれが正しいことを確認したい..私が見る多くの例では、工場ではなくリポジトリで動作するコントローラーがあるため、ARの作成に工場が推奨されているのも見た..例では、コントローラーは集約ルートを処理していますが、「消費者」がARを取得するためにARを照会する必要があるような方法:

お気に入り：

またはさらに良い：

次のようになります。

この場合、リポジトリは私のニーズに合わせて ClientAR を「満たす」ように感じたので、使用状況に応じて変化するこの ClientAR を手に入れました。匂いがします..

工場から ClientAR を作成してから使用しているだけなので、工場を使用すると「気分が良くなります」。状況に応じて変化するわけではありません。

または、私はそれを完全に見逃しているので、これを行う必要があります::

物事の仕様面が欠けていますか？（この時点では、仕様を実際に進めるには十分ではありません（まだ）、これを機能させる必要があるためです）

私は実装の詳細に行き詰まらないようにしています。もちろん、私のボスマンは私がそれを行う方法についてがらくたを与えないためです..これまでのところ、少なくともDDDについて考えて物事を実装しています（うまくいけば、私は得ていますそれは）、この「パターン」または「考え方」から生じる責任の論理的な「境界」と、テスト可能性で非常に優れていることが証明されています..

それで、私はこれに正しく近づいていますか？それが議論の余地がある場合は、私はそれで大丈夫です..それが単に間違っている場合は、ガイダンスは間違いなく高く評価されます.

前もって感謝します。