Я начал эту тему, потому что основные тенденции сейчас все выносить в сервисы, независимо от того, что это за код и обязательно называть это именно сервис типа BlahBlahBlahService, хотя Service это такое же ничего не значащее название как и Helper и т.п.
Если даже так повезло что вся бизнес логика вынесена отдельно (хотя ни разу не встречал, всегда инфраструктурные сервисы с доменными в одном месте вперемешку), то все равно сервисы представляют собой неструктурированную пачку всего чего только можно с просто хаотическими внутренними зависимостями от других сервисов. Даже если бы использовали разделение по упрощенному CQS, то структуривание было бы значительно лучше. Но нет, свалка сервис классов в одном месте - это уже статистика и негласный стандарт
Я не имею ничего против инструментов работы с сервисами во фреймворках, но сервис слишком общее и не точное название что-бы так называть конкретный класс. Т.е. понятно что фактически та же команда или квери (или их хандлеры) из CQRS могут быть сервисами, но называться они все равно будут или командой или квери, но не сервисом.
Т.е. вся эта лапша все тот же процедурный код, но завернутый в сервисы. Если раньше все писали процедурно, но потом это стало порицаемым, то потом заменили на статические методы в классах. Но и опять это стало порицаемым, вот теперь выносим все в сервисы с обращением через сервис локатор (нормальное di освоить могут единицы). Но блин это все то же процедурное php гуано (процедурно, тоже можно писать хорошо, но это точно не умеют 99.9% php разработчиков ибо хардкор)
И этому способствуют все мануалы фреймворков, там же все примеры используем такой сервис, внедряем такой сервис. Но неокрепшие умы юных дарований не понимают что сервисы и di во фреймворках это технический аспект реализации, а не способ организации кода. Потому и выносят вообще все в сервисы. Это как раньше когда везде в мануалах использовалась статика - везде юзали статику. Тоже самое насчет жирных активрекорд моделей и жирных контроллеров. Это статистика - если в мануале популярного фреймворка будет пример, то через пару лет это будет везде.
Тут кто-то говорил что пофиг как и кто пишет, главное самому писать нормально. Но проблема в том, что я занимаюсь внедрением, сопровождением и расширением
сторонних готовых продуктов и для меня это ооочень важно. Потому и возникают вопросы как в данной теме или вопросы насчет aop и подобного.
P.S. И да меня бомбит...