5

典型的なOrderとOrderItemの例を考えてみましょう。OrderItemがOrder Aggregateの一部であると仮定すると、Orderを介してのみ追加できます。したがって、新しいOrderItemをOrder に追加するには、Repository を介して Aggregate 全体をロードし、新しいアイテムをOrderオブジェクトに追加して、Aggregate 全体を再度永続化する必要があります。

これには多くのオーバーヘッドがあるようです。Orderに 10 個のOrderItemsがある場合はどうなるでしょうか。このように、新しいOrderItemを追加するだけで、 10 個のOrderItemを読み取る必要があるだけでなく、これら 10 個のOrderItemをすべて再度挿入する必要があります。(これは、Jimmy Nillson が彼の DDD の本で採用したアプローチです。Aggregate を永続化するたびに、彼はすべての子オブジェクトをクリアしてから、再度挿入します。これにより、子の ID が変更されるため、他の問題が発生する可能性があります。データベースの IDENTITY 列のために毎回変更されます。)

Unit of Work パターンを Aggregate Root に適用して、何が変更されたかを追跡し、それらの変更のみをコミットすることを提案する人もいると思います。しかし、永続化ロジックがドメイン モデルに漏れているため、これは永続化無視 (PI) の原則に違反しています。

誰もこれについて前に考えたことがありますか？

モッシュ

4

3 に答える 3

1

DDD では、集約ルートが集約の境界内で一貫性を確保していると想定しているため、集約全体をデータベースからロードする必要があります。これらのルールをチェックするには、必要なすべてのデータをロードする必要があります。特定の顧客の注文の価値が $100000 を超えてはならないという要件がある場合、集約ルート (注文) は、変更を永続化する前にこのルールを確認する必要があります。これは、既存のすべてのアイテムをロードしてそれらの値を合計する必要があることを意味するものではありません。注文は、新しいアイテムを追加するときに更新される既存のアイテムの事前計算された合計を維持できます。このようにビジネス ルールをチェックするには、新しいアイテムを追加するときに、注文データのみを読み込む必要があります。

于 2010-05-06T14:34:22.683 に答える
1

このアプローチについて 100% 確信があるわけではありませんが、作業単位パターンを適用することが答えになると思います。アプリケーションまたはドメイン サービスでは、すべてのトランザクションを実行する必要があることに注意してください。変更した集約からのオブジェクトを使用して、作業単位クラス/オブジェクトを設定できます。その後、UoW クラス/オブジェクトに魔法をかけてもらいます (もちろん、適切な UoW を構築するのは場合によっては難しいかもしれません)。

hereからの作業単位パターンの説明は次のとおり です。

作業単位は、ビジネス トランザクション中にデータベースに影響を与える可能性のあるすべての操作を追跡します。完了すると、作業の結果としてデータベースを変更するために実行する必要があるすべてのことを把握します。

于 2014-03-22T21:30:06.647 に答える
1

これは問題になる必要はありません。一部の ORM は遅延リストをサポートしています。たとえば、リスト内の他のすべてのエンティティを実際に具体化することなく、注文エンティティをロードし、アイテムを Details コレクションに追加できます。

N/Hibernate がこれをサポートしていると思います。

ORM を使用せずに独自のエンティティ永続化コードを作成している場合は、ほとんど運がありません。ORMappers が無料で提供するのと同じダーティ トラッキング メカニズムを再実装する必要があります。

于 2010-05-06T08:56:16.167 に答える