警告頭字語の過負荷が近づいています!!! MVPパッシブビューパターンとDIを使用してTDDとDDDを実行しています。新しいテストを作成するたびに、プレゼンタークラスのコンストラクターに依存関係の後に依存関係を追加していることに気づきました。ほとんどがドメインオブジェクトです。依存性注入にファクトリを使用していますが、最終的にはIoCコンテナに移動する可能性があります。
コンストラクターインジェクション（プロパティインジェクションとは対照的に）を使用すると、依存関係がどこにあるかを簡単に確認できます。依存関係の数が多いということは、通常、クラスの責任が大きすぎることを示していますが、プレゼンターの場合、これを回避する方法がわかりません。
すべてのドメインオブジェクトを、仲介者として機能する単一の「ドメイン」クラスにラップすることを考えましたが、問題を修正するのではなく、問題を移動するだけだと直感しています。
私は何かが足りないのですか、それともこれは避けられないのですか？
多くの場合、メソッド（コンストラクター、関数など）に対する多数の引数は、コードの臭いです。すべての議論が何であるかを理解するのは難しいかもしれません。これは、同じタイプの引数が多数ある場合に特に当てはまります。彼らが混乱するのは非常に簡単で、微妙なバグを引き起こす可能性があります。
リファクタリングは「パラメータオブジェクトの導入」と呼ばれます。それが本当にドメインオブジェクトであるかどうかにかかわらず、それは基本的に、メソッドに渡されるパラメーターの数を最小限に抑え、それらにもう少しコンテキストを与えるデータ転送オブジェクトです。
最初から何かが必要な場合にのみ、コンストラクターでDIを使用します。それ以外の場合は、プロパティを使用し、他のアイテムの読み込みを遅延させます。TDD / DIの場合、必要なときにアイテムを挿入できる限り、コンストラクターにアイテムを追加する必要はありません。
私は常にデメテルの法則に従うことをお勧めします。コンストラクターにある必要があるすべてのDI神話に従わないことをお勧めします。Misko Hevery（Googleのアジャイルコーチ）は、彼のブログhttp://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/でそれを詳しく説明しています。
レイヤースーパータイプを持つことは悪い考えではないかもしれませんが、あなたのコードの臭いは何か他のものを示しているのではないかと思います。Geofflaneは、リファクタリングパターンであるIntroduceParameterObjectについて言及しました。この種の問題には良いパターンですが、それがこの状況に対処する方法であるかどうかは完全にはわかりません。
質問：ドメインモデルオブジェクトをコンストラクターに渡すのはなぜですか？
抽象化が多すぎるということもあります。信頼できるはずのコードの堅固な層が1つある場合、それはドメインモデルです。Customer、Vendor、およびProductクラスを処理するときに、これらが基本的なドメインモデルの一部であり、必ずしもポリモーフィズムを必要としない場合は、3つのIEntityオブジェクトを参照する必要はありません。
私のアドバイス：アプリケーションとドメインサービスを渡します。ドメインモデルを信頼します。
編集：
夜遅くまで問題を読み直してみると、あなたの「ドメインクラス」はすでにIntroduce Parameter Objectのリファクタリングであり、実際には午前3時に思ったようにLayerSupertypeではないことがわかりました。
また、プレゼンターの外部にあるアプリケーションコードでModelオブジェクトを参照する必要があるかもしれません。おそらく、モデルオブジェクトをプレゼンターに渡す前に、モデルオブジェクトの初期設定を行っているのでしょう。この場合、「ドメインクラス」のアイデアが最適かもしれません。初期設定がある場合は、IoCに移行するときに、CastleWindsorのファクトリーサポートのようなものを確認することをお勧めします。（他のIoCコンテナーにも同様の概念があります。）