Либу?

Так и я про это. Просто в нест уже есть nest g lib

Щас буду чекать, спасибо

Ну да. Она тебе даст возможность потом сделать @mylib/users/intrrfaces как на фронте так и на бэке

Если нужно можно и в npm засунуть если у тебя не монорепа

Короче, смотри в доке про либы

Воу, вот это пропустил, звучит очень круто

Сразу тебе и билдер будет, на базе нестовкого

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

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

Мне кажется, что ответственность сервисов — создавать интерфейсы к бизнес-логике

Если у тебя есть ендпоинт, который должен отдать тебе юзера с комментариями - то создай сервис который обслуживает этот контроллер, в нём метод, который обслуживает этот action, и в этом методе тяни юзера + комментарии + лайки одним запросом к базе. Не надо так атомарно делить доступ к данным

Я рассматриваю сервисы как application layer в терминах clean architecture

Дай пять!

На самом деле весь nest — это application layer

В смысле те сущности, которые он поставляет. Понятно, что в инфраструктурный слой он тоже проникает.

Всем привет, что может являться маршрутизатором в зависимости от условия для двух контроллеров?

middleware/nest-router или другое че то

тянуть всегда все одним запросом не вариант. Иногда лучше делать это несколькими простыми запросами

Делать всегда что-то одинаково не вариант. Иногда лучше делать это по-другому