非常に多くの明白な利点 (Active-Record パターン スクールから得られる) と、まだ不明な点がいくつかあるため、私たちは最近、私のチームで新しいプロジェクトに DDD を採用することを決定しました。
次のエンティティに依存するエンティティ トランザクションがあるとします (それぞれが他の非常に多くのエンティティに依存します): 1. 顧客 2. アカウント 3. 通貨
ファクトリを使用してトランザクション エンティティをインスタンス化して、複雑なビジネス ルールのためにドメイン サービスに渡す場合、これらすべての依存インスタンスをセットアップするために非常に多くのクエリを作成する必要がありますか?
このような依存関係をスキップするオーバーロードがファクトリにある場合、それらは場合によっては null になり、それらのプロパティにアクセスできるときとアクセスできないときを区別するのが複雑になりすぎます。Active-Record パターンでは、遅延読み込みを使用して、オンデマンドでのみ読み込むようにしています。DDDに関するアイデアはありますか?
編集：
私のシナリオでは、「トランザクション」が集約ルートの最良の候補のようです。アプリケーション サービス「InitiateTransaction」でメソッドを定義し (これには PayPal へのリダイレクトが含まれるため、「FinalizeTransaction」もあります)、AccountId、CurrencyId、LanguageId、およびその他のさまざまな外部キーとトランザクションを運ぶために必要な DTO をパラメーターとして受け取ります。属性。
ドメイン サービス (Transaction Processor および Fraud Rule Evaluator) を呼び出すときは、すべての依存関係 (「Transaction.Customer」、「Transaction.Currency」など) が読み込まれた「Transaction」集計を指定する必要があります。
したがって、私が正しければ、必要な手順は次のとおりです。 1.いくつかのリポジトリを呼び出して、顧客、通貨などを取得します。 2.上記で指定した依存関係を使用して TransactionFactory を呼び出し、トランザクション オブジェクトを取得します。行われるルール
正しい？さらに、私の懸念はステップ1と2についてでした。
「Customer」、「Currency」、およびその他のエンティティ/値オブジェクト「Transaction」が依存している場合は、他の依存関係があります。それらも設定しようとしますか？私がそうすると、アプリケーションサービスで非常に肥大化したコードになり、別のメソッドに配置するのにあまり再利用できないように思われるからです。ただし、あなたが提案したように「GetById(id)」を使用してリポジトリからそれらを取得しないと、「ユーザー」を返すプロパティ「Transaction.Customer.CreatedByUser」が必要であると言うように、コードがバグになる可能性があります。リポジトリはフラット インスタンスのみをロードするため、null になります。
編集：
結局、GetById(id) を使用して、自分のサービスで必要であることがわかっている依存関係のみを読み込むことになりました。フラットローディングのために誤って null インスタンスにアクセスするのはあまり楽しいことではありませんが、本番環境に持ち込まないようにユニットテストを行っています!!