317 Кб, 947x1280
Долго думал в какой тред написать, но так как вопрос слишком общий и любой бекендер оопшник может на него ответить - решил что лучше сюда. Если тема зайдет, то можем в целом архитектуру ваших приложений обсуждать.
У меня накопилось несколько вопросов, которые хотелось бы обсудить. В основном они крутятся вокруг паттерна Репозиторий и моего непонимания как с ним работать.
Есть приложение магазин. Там есть сущность Юзер, Заказ и Продукт.
1) Это три репозитория по ddd, верно? И каждый должен работать только с соответствующей ей сущностью? ЮзерРепо не должен возвращать Заказ, а Заказ не должен отдавать продукт.
2) Что делать если для оформления заказа мне надо обновить данные в нескольких репозиториях? Скажем уменьшить количество продуктов, пометить юзера и создать заказ. Как это обходится? Unit of work? А на каком уровне абстракции исполнять эту работу? В сервисе/контроллере? Где то ещё?
3) Иногда бывает так, что для оптимизации прямые сложные запросы в БД дешевле чем через репозиторий. Допустим пример: бизнесу надо увидеть список всех заказов за последнюю неделю и видеть информацию по юзеру и список продуктов у каждого заказа.
С точки зрения бд это один запрос на несколько join-ов. Он может быть не самый быстрый, но альтернатива ещё хуже: запускать метод OrderRepo.GetOrders(), после которого запускать в цикле UserRepo.GetById() вместе с ProductRepo.GetById().
Что делать в таком случае? Нарушать ddd?
У меня накопилось несколько вопросов, которые хотелось бы обсудить. В основном они крутятся вокруг паттерна Репозиторий и моего непонимания как с ним работать.
Есть приложение магазин. Там есть сущность Юзер, Заказ и Продукт.
1) Это три репозитория по ddd, верно? И каждый должен работать только с соответствующей ей сущностью? ЮзерРепо не должен возвращать Заказ, а Заказ не должен отдавать продукт.
2) Что делать если для оформления заказа мне надо обновить данные в нескольких репозиториях? Скажем уменьшить количество продуктов, пометить юзера и создать заказ. Как это обходится? Unit of work? А на каком уровне абстракции исполнять эту работу? В сервисе/контроллере? Где то ещё?
3) Иногда бывает так, что для оптимизации прямые сложные запросы в БД дешевле чем через репозиторий. Допустим пример: бизнесу надо увидеть список всех заказов за последнюю неделю и видеть информацию по юзеру и список продуктов у каждого заказа.
С точки зрения бд это один запрос на несколько join-ов. Он может быть не самый быстрый, но альтернатива ещё хуже: запускать метод OrderRepo.GetOrders(), после которого запускать в цикле UserRepo.GetById() вместе с ProductRepo.GetById().
Что делать в таком случае? Нарушать ddd?
В рот ебал этот ваш паттерн репозитория. Коллеги заебали его спамить. Уебки. Нет бы просто ручками все сделать, они сука городят костыль на костыле - тут блять транзакция не работает, тут сука нужен кастомный уровень транзакции на каждую репу. Ненавижу блять говнокодеров сука сеньоров, выблядков.
>>4925 (OP)
Репозиторий - это название для интерфейса, через который ты работаешь с бд. Исторический сложились термины контроллер, сервис, репозиторий - это все одно и то же по сути, просто из разных слоев. Когда ты пишешь юнит-тесты для кода, который ходит в бд, тебе надо замокать реальную базу. Ты берешь интерфейс, называешь его BlaBlaBlaRepository и используешь. Все просто.
ДДД придумали инфоцигане, чтобы продавать книжки по ДДД. К программированию эта хуита никакого отношения не имеет.
Репозиторий - это название для интерфейса, через который ты работаешь с бд. Исторический сложились термины контроллер, сервис, репозиторий - это все одно и то же по сути, просто из разных слоев. Когда ты пишешь юнит-тесты для кода, который ходит в бд, тебе надо замокать реальную базу. Ты берешь интерфейс, называешь его BlaBlaBlaRepository и используешь. Все просто.
ДДД придумали инфоцигане, чтобы продавать книжки по ДДД. К программированию эта хуита никакого отношения не имеет.
>>5282
Согласен.
>>4925 (OP)
Чел, DDD не так то просто нарушить.
DDD вообще не про репозиторий, репозиторий это хтонический паттерн для энтерпрайзных очкариков, известный со времен царя гороха. DDD - про bounded context и агрегаты там всякие, а репозиторий - просто привычная обертка для вышеперечисленного, не более того. Часто завозится в паре с ОРМом. И в тех местах, где проще выполнить один запрос с джойном, нет ничего зазорного в том, чтобы для этого запроса просверлить эксклюзивную дырку в репозитории, равно как нет ничего зазорного в том, чтобы просто выполнить его в обход всех ORMов и получить результат. Принципам DDD это никак не противоречит.
Согласен.
>>4925 (OP)
>Что делать в таком случае? Нарушать ddd?
Чел, DDD не так то просто нарушить.
DDD вообще не про репозиторий, репозиторий это хтонический паттерн для энтерпрайзных очкариков, известный со времен царя гороха. DDD - про bounded context и агрегаты там всякие, а репозиторий - просто привычная обертка для вышеперечисленного, не более того. Часто завозится в паре с ОРМом. И в тех местах, где проще выполнить один запрос с джойном, нет ничего зазорного в том, чтобы для этого запроса просверлить эксклюзивную дырку в репозитории, равно как нет ничего зазорного в том, чтобы просто выполнить его в обход всех ORMов и получить результат. Принципам DDD это никак не противоречит.