The key point here is that the Service Layer is thin - all the key logic lies in the domain layer.
In general, the more behavior you find in the services, the more likely you are to be robbing yourself of the benefits of a domain model.
I don't know why this anti-pattern is so common. I suspect it's due to many people who haven't really worked with a proper domain model, particularly if they come from a data background. Some technologies encourage it;
Фреймворки из вашей подписи действительно поощряют писать анемичные модели. Но это неверно. Бизнес-логика должна быть в моделях и только там. Сервис лишь вызывает методы модели изменяя таким образом её состояние, сохраняет изменившееся состояние модели в хранилище, возвращает DTO для контроллера и всякая такая второстепенная муть.
Тогда получится, что просто кладем проблему в другой класс. Этого не достаточно. Вот если бизнес-логику положить в модель. Модель вызывать из сервиса, а сервис из контроллера. Тогда это будет иметь смысл.
Да, slim это лучшее, что есть в php. Когда смотришь проекты на пухлых фреймворках, не видно ярко выраженной бизнес-логики, её пишут куда попало в перемешку с инфраструктурой. Код сильно связан. Чинишь дверь, выпадывает окно. Проблема конечно не в этих фреймворках, а в программистах, но безусловно, они подталкивают писать такой код.
StynuBlizz: второй вариант - это хранение ленты каждого пользователя. Я думаю, этот вариант придумал Олег Бунин. Кажется, что в реальности это не будет нормально работать. Я не знаю как вконтакте и фейсбуке сделано и не знаю как они масштабируют френдленту, но можно попробовать в англоязычном сегменте погуглить эти вопросы.
Не первый раз уже рассказывает про френдленту. Но ни слова о консистентности данных. Его френдлента сломается при первом же сбое. Подтверждает, что вконтакте сделано иначе, как в фейсбуке не знает.
Когда спрашивают о консистентности, отвечает "Я не знаю как. Ребята, давайте дальше". Думаю второй вариант от него пошел. Вы в рунете читали про второй вариант?
vasIvas: реклама google adsense. Платят за просмотры. Примерно 500$ за 1 млн. просмотров было раньше. Сейчас будет хорошо если выйдет хотя бы 200-300$. Как по мне занятие бесполезное.
Tom Nolane: всегда есть проблемы. Но качество ответов на SO, которые выдает гугл довольно высокое. Люди ленивы и обычно гуглят, прежде чем написать. Человек не нашел решение, пришел чтобы быстро получить ответ, а вы предлагаете ему положить на дедлайн. Если часто возникают дубли, то проблема скорее с индексацией в поисковиках. Внутренним поиском не пользуется никто. Все ищут по интернету. Внутренний поиск лучше делать по заголовку при создании поста. И не забывайте, что ваше присутствие на тостере началось с вопроса, а не с ответа. Врядли бы вам понравилось ваша идея, в тот момент.
Philipp: ну для меня тостер превратился в 5 минутку отдыха. Для серьезных вопросов есть стековерфлоу. Там сообщество в разы больше, воды меньше, а ответы эволюционируют с течением времени. На тостере всё наоборот. Я считаю тратить силы и делать серьезный ресурс в рунете мало смысла, когда есть конкуренты с бюджетом и возможностями в разы выше. Посмотрите на Яндекс. Вкладывают огромные средства в разработку, но рынок поиска теряют. Google даже без агрессивной экспансии в рунет выпилит его до нуля за несколько лет и все забудут что такое существовало, как забыли рамблер, апорт и всех остальных. Так что не нужно пытаться делать второй SO с геймификацией и бейджами. Время будет потрачено, кодовая база вырастет, расходы на поддержку тоже, а доходы нет.
HellWalk: да, это мало похоже на тестовое задание. Скорее кто-то хочет бесплатно получить готовый сайт. Настораживает внимание к деталям и уточнения вида "по веб разработке". Больше на тех. задание похоже.
Иван Артамонов: index.php не убирают, а скрывают, но в любом случае все урлы по которым физически на сервере ничего не существует, он редиректит на точку входа index.php, который лежит в корне. Соответственно, какую страницу сайта вы бы не открыли, ваш current path всегда будет равен директории где лежит index.php т.к все страницы вашего сайта динамические и физически их не существует на сервере (они все генерируются через index.php). Соответственно на любой динамически сгенерированой странице сайта (через index.php) все ассеты будут резолвиться относительно этого current path. Я мог бы вам показать, что именно так это и работает и я уверен в этом на 100%, но мне лень тратить своё время и разворачивать для вас демо, чтобы что-то вам доказать. Достаточно понять, что ваш веб сервер всегда обращается к файлу index.php, какую страницу сайта вы бы не открыли, если у вас одна точка входа, незвисимо от того, видите ли вы index.php в урл или нет. И соответственно все картинки без начального слеша будут отдаваться относительно директории того файла, к которому вы обратились, а это index.php для любой страницы вашего сайта.
Про тестеров я вам уже не раз писал. Если у вас есть специально обученный человек, которому не жить как приспичило тестировать каждую ветку в отдельности, то он может скачать эту конкретную ветку себе на дев машину и делать там всё, что он хочет не заморачивая голову остальным. Но вообще в крупных компаниях тестировщики работают не так, они плевать хотели на все эти ваши ветки, они ничего в них не понимают. У них есть чек-листы и именно по ним они проверяют конкретный билд, который собирается выйти в релиз. Это не ветка и не одна фича, это то, что уже реально готово выйти на продакшн как next version. Если тестеры заворачивают этот билд, то разработчики правят то, что тестировщиков не устраивает и выкатывают новый билд. И для таких вещей есть stage. Ваша проблема в том, что вы сами же придумали себе проблему, а теперь пытаетесь героически её решить.
На этом всё. В дальнейшую дискуссию не вступаю, поскольку мне больше нечего сказать, по вашей теме.
GhostSt92: согласен, что жесть. Но вы же сами видите, что автору зачем-то нужно чтобы все ветки были доступны с удаленной машины, чтобы тестеры ходили по ним своими браузерами и что-то там тестили и другие варианты он принимать не желает. Я уже не однократно писал человеку, что разработчик сам тестирует фичу и что если уж автор хочет что-то там тестить руками или как-то еще, то может master выкатывать не сразу на prod, а не stage и делать это там.
Мне верить не надо, но с Фаулером стоит ознакомиться https://martinfowler.com/bliki/AnemicDomainModel.html
Фреймворки из вашей подписи действительно поощряют писать анемичные модели. Но это неверно. Бизнес-логика должна быть в моделях и только там. Сервис лишь вызывает методы модели изменяя таким образом её состояние, сохраняет изменившееся состояние модели в хранилище, возвращает DTO для контроллера и всякая такая второстепенная муть.