Сервисы можно понимать по-разному, они конфликтуют еще со "службами". Иногда в него кладут\ложат репозиторий и только лишь проксируют вызовы, выходит прокси сервис -> репозиторий, где можно репозиторий поместить в контроллер напрямую, чтобы не править каждый раз прокси. Это намекает, что сервис должен быть посложнее и разгружать контроллеры. Кроме бд ничто не мешает это делать и с любой другой логикой. Раз логика выносится, то доступа к другим сервисам\службам как у контроллера у неё нет\минимум. Это более легкий реюз за счет небольшого кол-ва зависимостей и на тех участках, где остальные нужные для контроллеров вещи еще не инициализированы, туда же многопоточность, меньше правок за счет единственной ответственности и т.п. Поэтому если реюза этой логики для процессов нет, то это похоже на контроллер, если другие контроллеры потребуют доступа к ней, то это уже больше похоже на сервис\службу, чтобы не завязывать контроллеры друг на друга, хотя смотря как там все устроено. Есть более нейтральные - manager, processor, etc, но опять таки это все зависит от наличия других похожих по функционалу модулей. Но это если есть связь название - функциональный слой, если нет, то мне кажется название не слишком критично и может быть любым.
В части директорий удобно деление на CCD - common, core, domain или аналог. А вот иерархия дальше интереснее, можно собрать слои в одном месте - controller(s)/page, controller/process или же page/controller, process/controller. Со вторым чуть не сел в лужу при портировании кода на новую java > 9, где для модульности нужен доступ на рефлексию. Еще если появляется общая логика между разными элементами, то для первого случая это не проблема, её можно хранить там же, а для второго - проблема, деление в нем более-менее равноценно и если эти папки\модули\пакеты переместить, то это задевает все остальное, что в них есть, а если выносить отдельно, то начинает формироваться первый вариант. Хотя если логика простая, то второй вариант выглядит удобнее, хотя и не факт, кгм...