この特定の問題に対処するための質問は見つかりませんでした。 サービス（またはファサード）が複数のDAO（データベースと通信するクラス）または他のサービスにのみアクセスできるようにするにはどうすればよいですか？サービスがいくつかのDAOまたは他のサービスにしかアクセスできないようにするにはどうすればよいですか
言い換えれば、異なるサービスクラス間の相互依存関係を導入すべきか、複数のDAO（必要ならば）を各サービスクラスに注入することによってサービスクラスを完全に独立させる方が良いでしょうか？
私は両方の戦略が仕事をすることがわかりましたが、私は一貫性を持たせ、可能な限りモジュール化して保守可能なアプリケーションにしたいと考えています。
サービスが別のサービスまたは複数のDAOを呼び出すことを許可または禁止することは主観的だと思います。 私は不必要なコードや奇妙な結合を避け、レイヤ通信に関するいくつかのルールを満足させるようにしています。単純で明確なオブジェクトを作る基本的なOOの原則に従えば、通常は妥協につながります。
サービスBが既にサービスAに含まれている別の機能を必要とする場合は、それを呼び出す必要があります。私はサービス間の依存関係を減らそうとし、通常、他のサービスから呼び出すことができる「基本」サービスの小さなセットを定義します。
サービスを呼び出してDAOにラップするメソッドを作成するのは無意味です（私の意見では）ので、サービスは必要なだけ多くのDAOを呼び出すことができます。ここでも、多くのDAOを持つサービスやメソッドは、リファクタリングすべきもの、または調整が必要なデータモデルを示しています。
は確かにこの中にいくつかの意見があるのですが、本当の「サービス」の方法は、作業の原子単位でなければなりません。相互依存関係のWebを作成してお互いを後方に横向きに呼び出そうとしている場合、呼び出しは原子的なタスクを実行していません。私は、 "サービス"に必要なDAOを使用させることに何も悪影響を与えません。すでにCRUDメソッドの集合であるDAOを抽象化している "サービス" -CRUDメソッドのセットを作成すると、おそらくJPAである抽象化を抽象化しているかもしれませんが、非機能抽象化のレベルが高すぎるかもしれません。
このアプローチでは、複数のサービスが共有するサービスではなく、ドメイン内にある共有「ビジネスビーンズ」を構築することがあります。これは問題ありません。
（あなたは私が個人的にJPAは時代遅れのDAOの全体の考え方をしていると私たちはサービスにEntityManagerを使用すべきだと思う言うことはできますか？:)）
だからである「基本サービス」の特別クラスを作成することをお勧め「通常の」サービスで使用できる唯一のサービスですか？また、サービス間でDAOを共有することができます（たとえば、他のサービスで使用するためにDAOメソッドをラップするのを避けるなど）。私にとって理にかなっていますが、これは混在戦略のようなものです（コードが一貫性のないものになっても、しばしば混在戦略が最適です）。 – Renato
特別な 'BasicService'を作ることは、あなたが気に入ったらそれを行うことができます。私は通常それらのうちのごく一部で終わったので、決して終わらなかった。したがって、それは独立したサービスへの傾向を持つ混合戦略です。 – madth3