サービスレイヤーを正しく使用していますか？

Question

私はDDDを読んでいますが、私はサービスを間違っているか、少なくともそれほど理想的ではない方法でサービスを使用している可能性があると思います。私のサービスクラスには、リポジトリ参照を含むかなりの数のインスタンス変数がある傾向があり、多くの作業を行っているようです（つまり、多くの方法があります）。

より集中的なサービスを作成することをお勧めしますか？特定のロジックを実行するサービスごとの1つのメソッドと同様に？また、サービスクラスはインスタンス変数を他のエンティティに保存する必要がありますか？私はサービスが無国籍であることについて何かを読みました、私はそれらのインスタンス変数を持つことによってそのルールを破っているかどうかはわかりません。

ありがとう！

Answer 1

私のサービスクラスには、かなりの数のインスタンス変数がある傾向があります...

これは必ずしもコードスメルではありません。サービスがその作業を完了するために多くの依存関係を必要とする場合、これは単なる事実です。

...彼らは多くの仕事をしているようです（つまり、多くの方法があります）。

より集中的なサービスを作成することをお勧めしますか？

一般的なルールとして、サービスインターフェイス（つまり、より少ない方法）を作ることができれば、より良い（電話をかけたいものを探して50のメソッドがあるインターフェイスをトロールする必要がありましたか？）。ただし、パブリックAPIとしてリリースしない限り、サービスインターフェイスの粒度を洗練することができます。多くの場合、プロジェクトを開始するとき、私は1つのサービスから始めて、時間の経過とともにそれを分割します。あなたがこれらのサービスの消費者である場合、インターフェイスが大きくなっていることの痛みを感じ始めたら、それを分割する時が来たことがわかります。もちろん、これはそうです は パブリックAPIでは、より多くの前払いデザインを行う必要があります。

また、サービスクラスはインスタンス変数を他のエンティティに保存する必要がありますか？私はサービスが無国籍であることについて何かを読みました、私はそれらのインスタンス変数を持つことによってそのルールを破っているかどうかはわかりません。

インスタンス変数として依存関係を保存することは、インスタンス変数もステートレスである限り、サービスがステートレスではないことを必ずしも意味するものではありません。ステートレスと見なされるために、サービスのメソッド呼び出しは、以前のメソッドが呼び出されたことに依存してはなりません。単一のインスタンスをロードし、アプリケーションのために共有することができるはずです（つまり、ステートレスサービスのインスタンスは特定のユーザーのセッションに固有のものではありません）。言い換えれば、サービスはメソッド呼び出しの間に状態を維持すべきではありません。 Statelessリポジトリの依存関係をサービスインスタンスに変数として保存しても、この要件に違反しません。

ステートレスサービスが望ましい目標である理由は、バグの可能性を大幅に減らす状態がないことです。これは、以前のサービスの状態を心配する必要があるのではなく、渡されたパラメーターを変化させるようにテストケースを制限することにより、サービス方法のテストを簡素化します。また、パフォーマンスの利点も提供できます。

Answer 2

依存関係の注入、コントロールの反転などを読むことをお勧めします。

これがファウラーの記事です： http://martinfowler.com/articles/injection.html, 、私はいつも彼が少し上にあることがわかりましたが。 DI/IOCコンテナの使用を表すチュートリアルを歩いてみます。