...Однако контролеры стали более объёмными, так как там добавилось сущностей и они теперь больше знают. Насколько я понимаю, мы перешли к какой-то другой архитектуре, не луковой/чистой.

А ещё показалось, что в луковой архитектуре, ну или том, подобии, что сделал я, не очень сложно тестировать бизнес-логику, по крайней мере в моём случае(Java + Spring). У нас же тут всё на DI и чтобы протестировать логику сервиса я могу просто в тесте вызывать методы этого сервиса, а ответ от БД замокать. И как будто получается почти то же самое, что и при переносе I/O в контроллеры. Также мы можем замокать ответы от сервисов/валидаторов в контроллере. Но возможно, что дело в Spring и его устройстве, а в других стеках всё иначе. Либо у меня пока мало опыта, чтобы осознать почему это плохо даже в Spring с его DI.

1. Какой контроллер мы можем считать "тонким"?
Тот, который вызывает лишь один метод или главное, чтобы такой контроллер не содержал в себе никакой бизнес-логики? И если контроллер будет вызывать валидатор, сервис, маппер, но при этом все эти вещи будут объявлены где-то в другом месте, а в контроллере нет никаких циклов/условий, то этот контроллер можно назвать "тонким".

2. Не совсем чётко понимаю границы "бизнес-логики". Что к ней относится? Вообще всё, что мы вычисляем на бэке(грубо говоря, есть цикл/условие или какое-нибудь преобразование данных -- то это бизнес-логика) или только то, что имеет отношение к нашей доменной области(тут имею в виду действия, совершаемые в рамках спецификации, ожиданий заказчика)? Является ли валидация входных параметров частью бизнес-логики? Или выбор нужного метода для обработки данных?

Глубокие вопросы, и действительно есть довольно тонкий и неочевидный нюанс. Тут нужно продвинутое понимание, чем луковичная архитектура отличается от гексагональной; мы думаем, что делаем порты и адаптеры, но нет -- это просто интерфейсы и полиморфизм, сермяга совсем в другом (чистая семантика домена и частично подходы из DDD). Подробно разберём на "Функциональных архитектурах".

Что интересно, если копать эту тему глубже, то мы придём к тому, что доказали ещё 100 лет назад Тьюринг и Чёрч, и даже Гёдель... Может ли быть язык (формальные спецификации), описывающий предметную область, Тьюринг-полным? В целом нет, но в каждом проекте мы можем к этому стремиться.

Мне тут очень нравится подход святого Эдвина Брэдли, автора Idris - языка с завтипами и пруф-ассистанта (см его книгу "Type-Driven Development with Idris"), который он пытается хотя бы немножко, хотя бы на уровне Хаскеля (так-то Idris его рвёт как тузик грелку), вывести в мэйнстрим. Брэдли предложил более прагматичное понятие "PacMan-полный" язык :)

Если мы можем закодить на некотором "тьюринг-неполном" языке игру в пакмэн, значит, он подходит для 80%..98% повседневных задач.

Точно так же и тут: я покажу, как один, по сути, "PacMan-полный" в архитектурном смысле паттерн (не парадигма, не концепция, не универсальность, как в Clean или DDD) даёт невероятную, буквально магическую, силу. Подходит он не всегда и не везде, но когда попадает в цель...