DDD のサービスについて少し混乱しています。
初めに。サービスが常にインターフェイスとして表現されるのはなぜですか? それはルールですか？
サービスにメソッドが 1 つしか含まれていないのはなぜですか? 関連するメソッドを 1 つのクラスに実装することが理にかなっている場合があります。
リポジトリごとにサービスを作成する必要がありますか? CRUD 操作のサービスを作成していることに気付いたので、何か間違ったことをしているに違いありません。
たとえば、通常の方法でリポジトリがあります。リポジトリに永続化されたオブジェクトへのアクセスを制御するにはどうすればよいですか? 私は読み方の多いサービスを作りがちです。これらのサービスは、ユーザーの役割を確認してから、ユーザーがオブジェクトを使用できるかどうかを判断できます。私のデザインに何かが足りない気がします。
ドメインサービスについて話していると思います。DDD には、アプリケーション サービスやインフラストラクチャ サービスなど、他の種類のサービスがあります。
初めに。サービスが常にインターフェイスとして表現されるのはなぜですか? それはルールですか？
いいえ、これはルールではありません。インターフェイスの抽象化は、必要な場合にのみ作成してください。
サービスにメソッドが 1 つしか含まれていないのはなぜですか? 関連するメソッドを単一のクラスに実装することが理にかなっている場合があります。
単一のメソッドを持つサービスは、単一の操作 (単一のユース ケース) を実装していると考えることができます。複数の操作を単一のオブジェクトにカプセル化することが理にかなっている場合は、これも許容されます。ただし、複数の責任を 1 つのクラスにまとめると、多くの場合、SRP 違反につながります。
リポジトリごとにサービスを作成する必要がありますか?
いいえ。リポジトリはすでに一種のサービスです。より具体的には、リポジトリの実装はインフラストラクチャ サービスと考えることができます。
ユースケースを実装するためにリポジトリを呼び出すアプリケーション サービスです。ドメイン エンティティに委任し、特定の操作に必要な他のサービスを調整します。相互作用するさまざまなサービスの例については、DDD のサービスをご覧ください。