Springに関する限り、区別はありません。慣例により、DAOクラスを@Repositoryでマークし、サービスを@Serviceでマークできます。また、前者はいくつかの永続化層の例外変換を行います。
あなたは理論的に尋ねているので：DAOは生のデータベース操作を実行し、それらをいくつかのより高いレベルの構造（オブジェクト、コレクション）に変換する必要があります。サービスはDAOを呼び出してビジネスオペレーションを実行する必要があります。通常、トランザクションの境界設定は、いくつかのDAO呼び出しにまたがるためにサービス層で実行されます。
最後に、DAOは永続性の詳細からビジネスロジックを抽象化し、理想的にはビジネスロジック（サービス）を変更せずに永続性レイヤーを切り替えることができるようにする必要があります。これは、永続プロバイダーのリークの抽象化のためにほとんど不可能です（例：遅延読み込み）。
DAO-データアクセスオブジェクトは、データストレージ（通常はデータベース）への接続を処理するオブジェクトです。ここにクエリがあり、DAOがサービスにデータを提供します。
サービスにはすべてのロジックが含まれている必要があります。ロジックが分離している場合、理論的にUIレイヤーまたはDAOレイヤーを変更せずに変更できます。
DAO（データアクセスオブジェクト）は、データベース上の各テーブルにクラスを作成することで構成されるデザインパターンであり、オブジェクトの永続性とデータアクセスロジックを分離するための手法を提供します。
デカップリングの利点があります。データのソースが変更されても、すべてのサービスユーザー（モバイルクライアント、Webクライアント）のサービスでデータを処理する方法は変わりません。ただし、データソースからデータを抽出する方法を変更する必要があります。
