Народ, а может кто-нибудь объяснить: за что ответственны сервисы? Как разграничивать логику?
Допустим, есть у меня сервис пользователя. У пользователя есть комментарии. Я должен получить пользователя вместе со всеми его комментариями.
а) в сервис пользователя и инжектю репозиторий юзера и репозиторий комментариев и делаю запросы к этим двум репозиториям
б) в сервис пользователя  делаю инжект репозитория пользователя и сервиса комментариев и получаю комментарии через сервис комментариев

Когда в сервис инжектить другие репозитории, а когда другие сервисы?

Народ, а может кто-нибудь объяснить: за что ответственны сервисы? Как разграничивать логику?
Допустим, есть у меня сервис пользователя. У пользователя есть комментарии. Я должен получить пользователя вместе со всеми его комментариями.
а) в сервис пользователя и инжектю репозиторий юзера и репозиторий комментариев и делаю запросы к этим двум репозиториям
б) в сервис пользователя  делаю инжект репозитория пользователя и сервиса комментариев и получаю комментарии через сервис комментариев

Когда в сервис инжектить другие репозитории, а когда другие сервисы?

Такое редко, в основном тока для ботов когда трилион запросов, люди так не могут, и потход графа вывозит

Важны когда много данных и тогда нужно на уровне запросов к базе решать

Это всего лишь детали доступа к бд, система должна проектироваться так, чтобы бд можно было легко заменить

Противник хранимых процедур detected :)

А у них есть сторонники?

Хранимки - это архитектурный ад

Да, и их очень много) Я один из них, кстати.
Я считаю, что датацентричные приложениия можно (и нужно) разрабатывать в базе данных.

Хранимки выполняются ближе всего к данным. Также они всегда выполняются в транзакции.
Это даёт прямо-таки суперсилу. Вещи, которые на JS занимают пару дней и 1000 строк кода в БД делаются за пару часов и 100 строк кода

Ну возможно, я бы не хотел строить OLAP-кубы в приложении.

Я бы вообще не стал делать датацентричное приложение на js :)