私は DDD について調べてきましたが、サービスを間違って使用しているか、少なくともあまり理想的ではない方法で使用していると思います。私のサービス クラスは、リポジトリ参照を含むかなりの数のインスタンス変数を持つ傾向があり、多くの作業を行っているように見えます (つまり、多くのメソッドがあります)。
より焦点を絞ったサービスを作成することをお勧めしますか? 特定のロジックを実行するサービスごとに 1 つのメソッドが好きですか? また、サービス クラスはインスタンス変数を他のエンティティに格納する必要がありますか? サービスがステートレスであることについて何か読んだことがありますが、それらのインスタンス変数を持つことでそのルールを破っているのかどうかはわかりません。
ありがとう！
私のサービスクラスには、かなりの数のインスタンス変数がある傾向があります...
これは必ずしもコードの匂いではありません。サービスがその作業を完了するために多くの依存関係を必要とする場合、これは単なる事実です。
...彼らは多くの仕事をしているようです (つまり、たくさんのメソッドがあります)。
より焦点を絞ったサービスを作成することをお勧めしますか?
原則として、サービス インターフェイスを細かくするほど (つまり、メソッドが少ないほど) 優れたものになります (呼び出したいメソッドを探すために、50 個のメソッドを含むインターフェイスをトロールする必要があったことはありませんか?)。ただし、パブリック API としてリリースする場合を除き、サービス インターフェイスの粒度は、作業を進めるにつれて洗練されます。多くの場合、プロジェクトを開始するとき、私は 1 つのサービスから始めて、時間をかけて分割します。あなたがこれらのサービスの利用者である場合、インターフェイスが大きくなることに苦痛を感じ始めたとき、それを分割する時が来たことがわかるでしょう。もちろん、これがパブリック API である場合は、事前にさらに多くの設計を行う必要があります。
また、サービス クラスはインスタンス変数を他のエンティティに格納する必要がありますか? サービスがステートレスであることについて何か読んだことがありますが、それらのインスタンス変数を持つことでそのルールを破っているのかどうかはわかりません。
依存関係をインスタンス変数として保存しても、インスタンス変数もステートレスである限り、必ずしもサービスがステートレスではないことを意味するわけではありません。ステートレスと見なされるためには、サービスのメソッド呼び出しは、以前に呼び出されたメソッドにまったく依存してはなりません。サービスの単一のインスタンスをロードして、それをアプリケーションで共有できる必要があります (つまり、ステートレス サービスのインスタンスは、特定のユーザーのセッションに固有であってはなりません)。つまり、サービスはメソッド呼び出し間で状態を維持してはなりません。ステートレス リポジトリの依存関係をサービス インスタンスの変数として格納することは、この要件に違反しません。
ステートレス サービスが望ましい目標である理由は、ステートを持たないことでバグの可能性が大幅に減少するためです。サービスの以前の状態について心配する必要がなく、渡されたパラメーターを変更するテスト ケースを制限することで、サービス メソッドのテストを簡素化します。また、パフォーマンス上の利点も提供できます。
依存性注入、制御の反転などについて読むことをお勧めします。
Fowlerの記事は次のとおりです。DI/IoC コンテナーの使用を表すチュートリアルを見てみましょう。