Service классы в PHP

Yoskaldyr

Новичок
Партнер клуба
В последнее время пересмотрел большое количество готовых решений и складывается впечатление, что в 90% случаев разработчики когда не знают куда отнести код - выносят его в сервис :) И очень часто это именно бизнес логика. Не говоря о том что эти сервисы вызывают вообще откуда угодно :(

Что с этим делать? Или просто понять и простить?
 

Adelf

Administrator
Команда форума
Понять и простить. Это нормальный этап в развитии. Потом обычно понимаешь, что сложной логике очень неуютно в сервисах и сложно ее не дублировать и т.д. Но это потом :) Я года три назад был уверен, что только так и надо. Могу даже найти свои посты тут об этом.
 

Yoskaldyr

Новичок
Партнер клуба
@Adelf тогда где лучше размещать этот бизнес код и как это тогда называть?
Может есть на примете хороший пример выделения бизнес логики не в сервисы и желательно чтобы продукт был большой, а не тестовый пример?

P.S. Понятно что с тем с чем в данный момент трахаюсь я ничего сделать не смогу, но значительно легче когда знаешь что может быть лучше.
 

fixxxer

К.О.
Партнер клуба
Почитай про DDD уже наконец. Там ответы на все вопросы. В комментарии на форуме я не смогу изложить материал на 1000 страниц :) А более простого ответа не существует.
 

Yoskaldyr

Новичок
Партнер клуба
почитал и давно. вопрос о примерах живого а не синтетического приложения.и желательно приложения не из одного действия
 

Yoskaldyr

Новичок
Партнер клуба
по ддд (по крайней мере так разработчики позиционировали код) видел только одно большое приложение (не опенсорс, так что не могу привести пример, да и доступа к исходникам сейчас нет).
И даже там весь непонятный код (непонятный, в смысле что не придумали куда отнести) был вынесен в сервисы.
И хотя все сервисы были в своих доменных областях, но фактически эти сервисы были практически равны набору статических хелперов (разве что оформлено не статикой)

Поставлю вопрос немного по другому, что должно/может быть в сервисах, а чего точно нет/не желательно? Вопрос не имеет смысла исходя из текущей статистики - все равно будут пихать в сервисы всякое гуано :(
 
Последнее редактирование:

Yoskaldyr

Новичок
Партнер клуба
И еще, по идее более логично именовать сервисы по CQRS, тогда и код чище названия классов имеют в разы больший смысл.

Но вопрос, почему никто этого не делает??????? Или тоже понять и простить???
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Слушай, какая разница что другие делают?) Нормально делай, нормально будет!)
 

Adelf

Administrator
Команда форума
Строго говоря, ДДД не про то, как код структурировать :) но и пофиг.
В идеальном случае, разработчик начинает строить приложение с домена. Формирует сущности, Value Objects, и другие AR, просто как можно удобнее моделируя предметную область(домен). Он не думает про базу данных, не думает про UI. Он общается с экспертами, пытаясь полностью понять домен и наиболее правильно выразить его в коде(про это кстати книжка Эванса).
Юнит-тесты для таких классов пишутся очень легко. Вообще не в напряг и TDD всякое работает идеально.
А уже потом, он начинает интегрировать построенную нашу модель в реальный мир. Появляется хранилище данных. Можно кстати выбрать просто хранить события и получить ES. Потом появляется UI и ты понимаешь, что для того, чтобы построить API или UI придется открыть чуть ли не все поля, которые были приватными.. или сделать для них геттеры, что тоже не айс. И в голове появляется идея про CQRS. Тупо убрать чтение в отдельный программный модуль. Как-то так.
В такой модели сервисы будут просто соединять нашу модель с реальным миром, ну или выполнять другие инфраструктурные вещи, типа сгенерить картинку и ее thumbnails.
 
Последнее редактирование:

ivanov77

Новичок
И еще, по идее более логично именовать сервисы по CQRS, тогда и код чище названия классов имеют в разы больший смысл.

Но вопрос, почему никто этого не делает??????? Или тоже понять и простить???
Я много чего перерыл про Service Layer и нигде не встречал такой формулировки.
Хотя если подумать то каждый сервис вокруг одной ответственности и так должен крутиться.
Пример неудачного?
 

Yoskaldyr

Новичок
Партнер клуба
Я начал эту тему, потому что основные тенденции сейчас все выносить в сервисы, независимо от того, что это за код и обязательно называть это именно сервис типа BlahBlahBlahService, хотя Service это такое же ничего не значащее название как и Helper и т.п.

Если даже так повезло что вся бизнес логика вынесена отдельно (хотя ни разу не встречал, всегда инфраструктурные сервисы с доменными в одном месте вперемешку), то все равно сервисы представляют собой неструктурированную пачку всего чего только можно с просто хаотическими внутренними зависимостями от других сервисов. Даже если бы использовали разделение по упрощенному CQS, то структуривание было бы значительно лучше. Но нет, свалка сервис классов в одном месте - это уже статистика и негласный стандарт :(

Я не имею ничего против инструментов работы с сервисами во фреймворках, но сервис слишком общее и не точное название что-бы так называть конкретный класс. Т.е. понятно что фактически та же команда или квери (или их хандлеры) из CQRS могут быть сервисами, но называться они все равно будут или командой или квери, но не сервисом.

Т.е. вся эта лапша все тот же процедурный код, но завернутый в сервисы. Если раньше все писали процедурно, но потом это стало порицаемым, то потом заменили на статические методы в классах. Но и опять это стало порицаемым, вот теперь выносим все в сервисы с обращением через сервис локатор (нормальное di освоить могут единицы). Но блин это все то же процедурное php гуано (процедурно, тоже можно писать хорошо, но это точно не умеют 99.9% php разработчиков ибо хардкор)

И этому способствуют все мануалы фреймворков, там же все примеры используем такой сервис, внедряем такой сервис. Но неокрепшие умы юных дарований не понимают что сервисы и di во фреймворках это технический аспект реализации, а не способ организации кода. Потому и выносят вообще все в сервисы. Это как раньше когда везде в мануалах использовалась статика - везде юзали статику. Тоже самое насчет жирных активрекорд моделей и жирных контроллеров. Это статистика - если в мануале популярного фреймворка будет пример, то через пару лет это будет везде.

Тут кто-то говорил что пофиг как и кто пишет, главное самому писать нормально. Но проблема в том, что я занимаюсь внедрением, сопровождением и расширением сторонних готовых продуктов и для меня это ооочень важно. Потому и возникают вопросы как в данной теме или вопросы насчет aop и подобного.


P.S. И да меня бомбит...
 

fixxxer

К.О.
Партнер клуба
Совершенно верно, и это все идет от анемичных моделей. Анемичная модель - это как сишная структура или паскалевский record, а сервис - это набор процедур. Никакого ООП в этом нет.

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

Adelf

Administrator
Команда форума
И этому способствуют все мануалы фреймворков, там же все примеры используем такой сервис, внедряем такой сервис.
Я недавно встретил прикольную фразу Tutorial Driven Development - TDD :)
 
Сверху