domain-driven-design - DDD のパフォーマンスの問題 AR 子エンティティの熱心な読み込み

Question

ここ数日、DDD を適用/学習するためのサンプル アプリケーションを作成しています。DDD の原則の 1 つ (間違っている場合は訂正してください) は、エンティティへのすべての変更は Aggregate Root(AR) を介して行う必要があり、AR はその子エンティティと共に読み込まれる必要があるということです。このようにして、集計の一貫性を検証しやすくなります。私を悩ませているのはほんの少しの大きな詳細です。DDD がパフォーマンスの問題にどのように対処しているか理解できません。たとえば、20000、30000 の OrderLine を持つ Order(AR) があるとします。多くの子レコードを熱心にロードすると、パフォーマンスの問題が発生する可能性があります。Order as AR と言うと、これが発生する可能性のある別のシナリオを想像できます。この件に関するあなたの意見を読むのを楽しみにしています。

Answer 1

DDD は常に技術的な考慮事項から解放されているわけではありません。非常に多数の子エンティティを含むことができる AR がある場合は、子エンティティを独自の AR にすることができるかどうかを検討してください。この決定は、結果整合性を考慮して行う必要があります。

提供された例では、完全性を維持するために Order AR が最初に OrderLine エンティティを参照する必要があるかどうかを検討してください。その場合、OrderLine をそれ自体で AR にすることを検討してください。その場合、結果整合性に対処する必要がある場合があります。もちろん、OrderLine を AR にすると、アプリケーション ロジックが変わります。なぜなら、OrderLine で実行する必要がある操作は、OrderAR ではなく、OrderLineRepository を介して OrderLine にアクセスする必要があるからです。

詳細については、Vaughn Vernon による「Effective Aggregate Design 」を参照してください。