1

うまくいけば、この架空の例が私の問題を説明するでしょう:

ソフトウェア製品に関する苦情や、製品に関するその他の多くの属性を追跡するシステムを作成しているとします。この場合、SoftwareProduct は集約ルートであり、Complaints は製品の子としてのみ存在できるエンティティです。つまり、ソフトウェア製品がシステムから削除された場合、苦情も削除されます。

システムには、単一の SoftwareProduct のさまざまな側面を表示する Web ページのようなダッシュボードがあります。ダッシュボードの 1 つのセクションには、グリッドのような形式で苦情のリストが表示され、各苦情について非常に高レベルの情報のみが表示されます。管理者タイプのユーザーがこれらの苦情のいずれかを選択すると、単一の苦情の詳細を編集できる編集画面が表示されます。

問題は、編集画面で単一の苦情を取得し、編集目的で表示できるようにするための最良の方法は何ですか? SoftwareProduct は既に集約ルートとして確立されているため、苦情への直接アクセスは許可されないことに注意してください。また、システムは NHibernate を使用しているため、eager loading はオプションですが、SoftwareProduct を介して 1 つの Complaint をeager load しても、Complaints コレクションにアクセスするとすぐに残りのコレクションが読み込まれると理解しています。では、Complaints コレクション全体をロードするオーバーヘッドを発生させずに、SoftwareProduct を介して単一の Complaint を取得するにはどうすればよいでしょうか?

4

5 に答える 5

5

これはセマンティクスと宗教性に少し入りますが、苦情を編集するという文脈では、苦情はルートオブジェクトです。苦情を編集する場合、親オブジェクト（ソフトウェア製品）は重要ではありません。それは明らかにユニークなアイデンティティを持つ実体です。したがって、更新された苦情などの保存に専念するサービス/リポジトリがあります。

また、あなたは少しネガティブすぎていると思います。苦情？「コメント」はどうですか？または「ConstructiveCriticisms」？

于 2009-11-21T05:14:35.790 に答える
1

@ジョシュ、

ドメイン モデル自体に基づくのではなく、パフォーマンスのためだけに「Web」アプリケーションをこのように設計する人がいることに気付きましたが、あなたの言っていることに同意しません。

私も DDD の専門家ではありませんが、従来の Order と OrderItem の例を読んだことはあると思います。すべての DDD ブックでは、OrderItem は Order 集約に属し、Order が集約ルートであると述べています。

あなたが言っていることに基づいて、ユーザーは OrderItem を重要ではない OrderItem で直接編集したいかもしれないので、 OrderItem はもはや Order 集約に属していません (その親ソフトウェア製品が重要ではない Complaing を編集するのと同じように)。そして、このアプローチに従えば、電子商取引システムに関して非常に重要な順序の不変条件を強制することはできません。

誰にもより良いアプローチがありますか？

モッシュ

于 2010-04-01T06:28:59.750 に答える
1

あなたの質問に答えるには：

集計は、一貫性を保つために使用されます。たとえば、親 (集約ルート) から子オブジェクトを追加/変更/削除すると、不変条件が壊れる場合、そこに集約が必要です。

ただし、あなたの問題では、SoftwareProduct と Compliant は 2 つの別個の集約に属し、それぞれが独自の集約のルートになっていると思います。新しい苦情を追加するためだけに、SoftwareProject とそれに割り当てられた N 個の苦情すべてをロードする必要はありません。私には、新しい苦情を追加するときに評価するビジネス ルールがないように見えます。

したがって、要約すると、SoftwareProductRepository と ComplaintRepository という 2 つの異なるリポジトリを作成します。

また、SoftwareProduct を削除する場合、データベース リレーションシップを使用して削除をカスケードし、関連する苦情を削除できます。これは、データの整合性を保つためにデータベースで行う必要があります。リンクされたオブジェクトの削除以外に他の不変条件がない限り、ドメイン モデルでそれを制御する必要はありません。

お役に立てれば、

モッシュ

于 2010-04-13T06:48:06.003 に答える
0

私はモッシュに同意します。これら 2 つのエンティティのそれぞれには、独自の集約ルートがあります。実生活で説明しましょう。ある会社がソフトウェアを開発したとします。このソフトウェアにはいくつかのバグがあり、ご迷惑をおかけしました。あなたは会社に行き、この問題から彼らに気づきます。この会社は、あなたが記入するフォームを提供します。

このフォームにはフィールド (セクション) があり、ソフトウェアの名前と説明を示します。さらに、それはあなたの苦情のためのいくつかの部分を持っています. このフォームはソフトウェアマニュアルと同じですか? いいえ、ソフトウェアに関するフォームです。ソフトウェアではありません。このフォームには ID がありますか? はい。あります。つまり、翌日に会社に電話して、オペレーターに苦情の手紙について尋ねることができます。オペレーターが ID について尋ねてくることは明らかです。

この証拠は、このフォームには独自のエンティティがあり、ソフトウェア自体と混同できないことを示しています。2 つの異なるエンティティ間の関係は、一方が他方に属していることを意味するものではありません。

于 2012-03-06T15:47:15.580 に答える
0

私は別のビジネス コンテキストに NH を使用していますが、あなたと同様のエンティティ関係です。なぜあなたが言うのかわからない：

SoftwareProduct はすでに集約ルートとして確立されているため、苦情への直接アクセスは許可されないことに注意してください。

私はこれを私の中に持っておりArticle、PublisherエンティティPublisherが存在しなくなった場合、依存するすべてのArtcleエンティティも存在しなくなります。個々のエンティティのArticleコレクションに直接アクセスできるようにします。クラスPublisherの DB/Mappingでは、はメンバの 1 つであり、 を受け入れることができません。ArticlePublisherNull

あなたのものと私のものとの違いを詳しく説明してみませんか？

申し訳ありませんが、これは直接的な回答ではありませんが、コメントとして追加するには長すぎます。

于 2009-11-21T04:33:22.970 に答える