oop - サービス層におけるサービスの相互作用

Question

サービス層でサービス間の相互作用を整理する最良の方法は何ですか? たとえば、ドキュメント サービスと製品サービスがあります。私の場合、製品は独自のドキュメントを持つことができ、製品のドキュメントを管理するために、製品サービスのドキュメント サービスから適切なメソッドを呼び出します。そのため、製品サービスでドキュメント サービスのインスタンスを作成する必要があります。また、ドキュメント サービスでも製品サービスからいくつかのメソッドを呼び出す必要があります。したがって、これらの各サービスは他のサービスを参照し、それぞれスタックオーバーフロー例外を取得します。これらの問題を解決するには、どの設計ソリューションを使用すればよいですか?

Answer 1

明らかに、循環依存は間違っています。

共有識別子を使用して と を切り離すことがProductできますDocument。

さらに、アプリケーション内でそれらの外部からサービスのやり取りを調整できます。ProductServiceLoadProducts(ProductIdentifiers[] identifiers)では不変の製品コレクションを返すことができ、DocumentServiceLoadDocuments(DocumentIdentifiers[] identifiers)では不変のドキュメント コレクションを返すことができます。

Answer 2

アプリケーション サービスは、まとまりのあるビジネス オペレーションを実行するための API を外部クライアントに提供することになっています。アプリケーション サービス メソッドは、通常、アプリケーションのユース ケースと一致します。

アプリケーション サービスの操作では、別のサービスを呼び出す必要がある場合があります (たとえば、Create Productユース ケースにはユース ケースが含まれており、Create Document個別に呼び出すこともできます) が、これは標準ではなく、アプリケーション サービスをできるだけまとまるようにする必要があります。特に、ビジネス ケースのある時点で別の種類のエンティティを操作し始めたからといって、その部分を別のアプリケーション サービスに委譲する必要があるわけではありません。つまり、エンティティごとに 1 つのアプリケーション サービスが適切であるとは限りません。

いずれにせよ、ドメインからは、2 つのアプリケーション サービス間の依存関係がどの方向を指しているかが明確に表示されるはずです。あなたの例では、Product Service は Document Service に依存しているようです。なぜ逆になるのか想像するのは困難です。

サービス A とサービス B の間の往復が本当に必要な場合 (他に選択肢がない場合を除き、これは行いません)、DI コンテナーに依存する代わりに、A のインスタンスを B に注入することができます。新しいインスタンスで依存関係を解決し、スタック オーバーフローの問題を解決します。最初にスタック オーバーフローが発生するのはそのためです。