アプリケーションでDIを使用する必要があるユースケースがわかりません。PlaceServiceなどのようなサービスの注入CalculationServiceが非常に適していることは知っていますが、？のようなDIを使用してドメインオブジェクトを作成する必要もありますUserか？Userに姓名を必要とするコンストラクターが1つしかない場合はどうなりますか。これはDIで解決できますか？
セット/リストインターフェイスのインスタンスを作成するためにDIを使用する必要がありますか、それともこれは純粋にやり過ぎですか？
私は主にguiceを使用します。
ig0774による答えは良い出発点です。さらに、この経験則を提供したいと思います。
ドメイン駆動設計の用語では、サービスに対してDIを行う必要がありますが、エンティティや値オブジェクトに対してはDIを行うべきではありません。
言い換えると、DIは、概念的に長寿命でステートレスなオブジェクトによく適合します。これらのオブジェクトには、通常1つまたは既知の数が使用されています。
私が使用するルールは、オブジェクトが純粋にプリミティブな値で構築でき、オブジェクトが別の実装に置き換えられる可能性がほとんどない場合を除いて、一般に依存性注入を優先することです。
ただし、ドメインオブジェクトの場合、特にオブジェクトが貧血のドメインモデルを構成していない場合、つまり、オブジェクトがゲッターとセッターの単なるバッグである場合は、たとえば、データストアなどに永続化できるオブジェクトがあると便利です。 。これらの種類のオブジェクトの場合、依存性注入とSalveは強力な組み合わせになる可能性があります。
Guiceには、 AssistedInjectと呼ばれるUserオブジェクトなどのオブジェクトによって引き起こされる問題のタイプに対する特定の解決策がありますが、他の軽量コンテナーや、ビルダーまたはアダプターパターンを使用する場合にも同様のことが可能です。