【spring】ControllerからEntityの役割について

役割はあなたの認識で合っていると思います。
しかし、きちんと分けるかどうかはシステムの規模や性質によると思います。小規模システムなら区別しなくてもいいと思います。

大規模システムの場合は意識しなければいけない場合があります。大規模システムの場合、サーバーを数十台とか数百台で運用するわけですが、その場合に1台の時と同じ構成・役割のサーバーを単純に並べる場合もあれば、役割で分割することもあります。大事なのは役割で分割する場合です。

つまり大規模なシステムではControllerとServiceのサーバーが異なっている場合があるのです。Controllerのサーバーではリクエストを受け付け処理結果を返すだけ。ServiceのサーバーはControllerに要求された処理を行いその結果を返す、という感じで。

当然、ControllerとServiceは通信が発生します。ので、何度もServiceを呼び出すとその回数分のネットワーク通信が発生するクソシステムになりますので、そうならないようにServiceで結果をまとめて返すようなコードを書くようになります。

例えば、特定の条件に合うユーザー一覧を表示する際に、まずユーザーリストをとって、その各ユーザの付加情報を別のテーブルからとってきてあわせて出力するとします。もちろん、DBで2つのテーブルをJOINして結果を返すDaoを作ることが最も望ましいのですが、めんどうなので既存のDaoだけを組み合わせて作ることはよくあります。

その際に、Controllerでまずユーザーを取得するServiceを呼び出し、さらに付加情報を取得するServiceをユーザー数分ループして呼び出すとすると、最初にとれたユーザーの件数によっては大変な量のネットワーク通信が発生することになるわけです。

なのでControllerにはServiceを呼び出すループは書いてはダメで、「ユーザーを取得するServiceを呼び出し、さらに付加情報を取得するServiceをユーザー数分ループして呼び出す」Serviceを作り、ControllerからはそのServiceを1回呼ぶようにすべきです。

という感じで大規模システムの場合、必然的にControllerとServiceの役割が明確に区別され、どちらで処理をさせるか悩むことは少なくなります。

一方で

実際に実装してみると、結局ControllerにDB以外の処理を実装してしまい、
Serviceですることがなくなって（Daoを呼び出すだけ）しまいました。
Controllerにどこまで処理を入れるか悩みどころですね。

こんな場合には、Serviceをなくしてしまってもいいと思います。

さらにページ数が20-30ページしかないし、アクセス数も少なくかつ将来も大量のアクセスが発生する心配のないようなシステムだったら、極論言えばJSPにSQLを書いてしまってもいいと思います。ユーティリティクラスはいくつか作ることにはなると思いますが、Controller・Service・Daoはなしで。そうすれば管理するファイルの数も減り、ほとんどの修正でコンパイルのし直しもしなくてよくなりますのでメンテナンスも簡単です。

規模に応じて適切な構成を考える、それが重要ではないかと思います。

大体の認識としてはそんなものかと。

「Dtoそのものをレスポンスとして返すのではなく、加工した構造体を返したい」
場合は、上げられた分類の他にViewModel(ViewObject,Vo)を作成することもあります。
DaoからEntityを取ってきてService層でViewModelに加工してController経由でViewに返すイメージですね。