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?
В рот ебал этот ваш паттерн репозитория. Коллеги заебали его спамить. Уебки. Нет бы просто ручками все сделать, они сука городят костыль на костыле - тут блять транзакция не работает, тут сука нужен кастомный уровень транзакции на каждую репу. Ненавижу блять говнокодеров сука сеньоров, выблядков.
>>14925 (OP)
Репозиторий - это название для интерфейса, через который ты работаешь с бд. Исторический сложились термины контроллер, сервис, репозиторий - это все одно и то же по сути, просто из разных слоев. Когда ты пишешь юнит-тесты для кода, который ходит в бд, тебе надо замокать реальную базу. Ты берешь интерфейс, называешь его BlaBlaBlaRepository и используешь. Все просто.
ДДД придумали инфоцигане, чтобы продавать книжки по ДДД. К программированию эта хуита никакого отношения не имеет.
Репозиторий - это название для интерфейса, через который ты работаешь с бд. Исторический сложились термины контроллер, сервис, репозиторий - это все одно и то же по сути, просто из разных слоев. Когда ты пишешь юнит-тесты для кода, который ходит в бд, тебе надо замокать реальную базу. Ты берешь интерфейс, называешь его BlaBlaBlaRepository и используешь. Все просто.
ДДД придумали инфоцигане, чтобы продавать книжки по ДДД. К программированию эта хуита никакого отношения не имеет.
>>15282
Согласен.
>>14925 (OP)
Чел, DDD не так то просто нарушить.
DDD вообще не про репозиторий, репозиторий это хтонический паттерн для энтерпрайзных очкариков, известный со времен царя гороха. DDD - про bounded context и агрегаты там всякие, а репозиторий - просто привычная обертка для вышеперечисленного, не более того. Часто завозится в паре с ОРМом. И в тех местах, где проще выполнить один запрос с джойном, нет ничего зазорного в том, чтобы для этого запроса просверлить эксклюзивную дырку в репозитории, равно как нет ничего зазорного в том, чтобы просто выполнить его в обход всех ORMов и получить результат. Принципам DDD это никак не противоречит.
Согласен.
>>14925 (OP)
>Что делать в таком случае? Нарушать ddd?
Чел, DDD не так то просто нарушить.
DDD вообще не про репозиторий, репозиторий это хтонический паттерн для энтерпрайзных очкариков, известный со времен царя гороха. DDD - про bounded context и агрегаты там всякие, а репозиторий - просто привычная обертка для вышеперечисленного, не более того. Часто завозится в паре с ОРМом. И в тех местах, где проще выполнить один запрос с джойном, нет ничего зазорного в том, чтобы для этого запроса просверлить эксклюзивную дырку в репозитории, равно как нет ничего зазорного в том, чтобы просто выполнить его в обход всех ORMов и получить результат. Принципам DDD это никак не противоречит.
Бамп нах.
Бамп годному треду. Этой доске не хватает треда по паттернам.
У меня на собесах спрашивают паттерны всякие, порождающие, структурные, поведенческие. А как они вообще используются на практике и нахуя их спрашивают? Все мои проекты за 6 лет работы это контроллеры, сервисы и репозитории. Все нахуй, никаких визиторов, интерпретаторов и стратегий. А вы используете это говно в своих проектах на джаве?
>>14925 (OP)
Да.
Создавать четвертый репозиторий OrderCreator.
На уровне модели, если используешь монолитную архитектуру presentation - application - model.
Что мешает написать функцию в репозитории с этим прямым и сложным запросом?
> Это три репозитория по ddd, верно?
Да.
> Что делать если для оформления заказа мне надо обновить данные в нескольких репозиториях?
Создавать четвертый репозиторий OrderCreator.
> А на каком уровне абстракции исполнять эту работу?
На уровне модели, если используешь монолитную архитектуру presentation - application - model.
> Иногда бывает так, что для оптимизации прямые сложные запросы в БД дешевле чем через репозиторий.
Что мешает написать функцию в репозитории с этим прямым и сложным запросом?
>>54625
Используются. Скорее редко чем часто.
Оценивают техническое любопытство. Достаточно ли ты задрот, чтобы изучить то, без чего ты бы и так спокойно выполнил свою работу.
Адаптер недавно использовал. Фасад понятное дело. Билдер постоянно. Интерсептор, но это больше года назад было. Может ещё какие-то неосознанно применял не зная, что они так называются. В целом на них похуй, меня больше пугает когда разработчик сует публичный интерфейс в публичный API библиотеки или когда ебашут глобальные классы для dependency injection.
> А как они вообще используются на практике
Используются. Скорее редко чем часто.
> нахуя их спрашивают?
Оценивают техническое любопытство. Достаточно ли ты задрот, чтобы изучить то, без чего ты бы и так спокойно выполнил свою работу.
> А вы используете это говно в своих проектах на джаве?
Адаптер недавно использовал. Фасад понятное дело. Билдер постоянно. Интерсептор, но это больше года назад было. Может ещё какие-то неосознанно применял не зная, что они так называются. В целом на них похуй, меня больше пугает когда разработчик сует публичный интерфейс в публичный API библиотеки или когда ебашут глобальные классы для dependency injection.
>>54625
Потому что могут. Там и литкод спрашивают, а в самом проекте соединяют строки через плюсик. Собеседования - это отдельный ритуал и к работе никакого отношения не имеет.
>нахуя их спрашивают?
Потому что могут. Там и литкод спрашивают, а в самом проекте соединяют строки через плюсик. Собеседования - это отдельный ритуал и к работе никакого отношения не имеет.
>>54625
Ну, по факту у тебя нет никакого опыта работы. Все твои "знания" укладываются в полуторачасовой курс. Действительно грамотную архитектуру ты никогда не видел. Т.е. у тебя буквально все познание в архитектуре это ЮзерКонтроллер, который инжектит в себя ЮзерСервис, дальше у тебя ЮзерСервисИмпл имплементс ЮзерСервис, который инжектит в себя ЮзерРепазитари. Это даже не уровень стажера, чел.. Неудивительно, что поколение альфа заменяет вас, скуфидонов
>Все мои проекты за 6 лет работы это контроллеры, сервисы и репозитории
Ну, по факту у тебя нет никакого опыта работы. Все твои "знания" укладываются в полуторачасовой курс. Действительно грамотную архитектуру ты никогда не видел. Т.е. у тебя буквально все познание в архитектуре это ЮзерКонтроллер, который инжектит в себя ЮзерСервис, дальше у тебя ЮзерСервисИмпл имплементс ЮзерСервис, который инжектит в себя ЮзерРепазитари. Это даже не уровень стажера, чел.. Неудивительно, что поколение альфа заменяет вас, скуфидонов
>>55459
Хуево тролишь.
Хуево тролишь.
>>55459
Ты мою работу выполнять все равно не сможешь, хуесос. Работа это не только про архитектуру. Был у нас уже такой архитектор, который пытался вместо задач делать архитектуру и лез в залупу. Не прошел у нас испытательный срок.
Ты мою работу выполнять все равно не сможешь, хуесос. Работа это не только про архитектуру. Был у нас уже такой архитектор, который пытался вместо задач делать архитектуру и лез в залупу. Не прошел у нас испытательный срок.
>>55430
Даачую. Я бы завел новый интерфейс-репозиториц прд эту задачу, типа OrderCreator или OrderManager. Все запросы описаны через sql, без ормок. И собственно сам запрос у тебя транзакционный где ты делаешь
все что тебе нужно. Про третий пункт то же самое. В отдельный репо или в тот же OrderManager (зависит от логики) делаешь метод с твоим сложным запросом и все
>>54625
Да постоянно эти паттерны всплывают. Паттерн стратегия это БУКВАЛЬНО ПРОСТО ИНТЕРФЕЙС. Если вы не пользуетесь паттерном стратегия значит что то не так. Пораждающие паттерны вообще постоянно всплывают, везде нужны фактори методы, часто нужны билдеры. Структурные паттерны тоже постоянно всплывают. Мне очень часто надо делать декораторы и адаптеры. Помимо стратегии из поведенческих недавно пользовался обзервером. Хз, мне кажется мы просто не задумываемся о том что тот код который мы пишем это на самом деле уже и есть какие то паттерны. Просто это стало настолько естественным способом что то сделать.
Даачую. Я бы завел новый интерфейс-репозиториц прд эту задачу, типа OrderCreator или OrderManager. Все запросы описаны через sql, без ормок. И собственно сам запрос у тебя транзакционный где ты делаешь
все что тебе нужно. Про третий пункт то же самое. В отдельный репо или в тот же OrderManager (зависит от логики) делаешь метод с твоим сложным запросом и все
>>54625
Да постоянно эти паттерны всплывают. Паттерн стратегия это БУКВАЛЬНО ПРОСТО ИНТЕРФЕЙС. Если вы не пользуетесь паттерном стратегия значит что то не так. Пораждающие паттерны вообще постоянно всплывают, везде нужны фактори методы, часто нужны билдеры. Структурные паттерны тоже постоянно всплывают. Мне очень часто надо делать декораторы и адаптеры. Помимо стратегии из поведенческих недавно пользовался обзервером. Хз, мне кажется мы просто не задумываемся о том что тот код который мы пишем это на самом деле уже и есть какие то паттерны. Просто это стало настолько естественным способом что то сделать.
>>55550
Как одно исключает другое?
Как одно исключает другое?
>>55550
Эм, почему это противопоставление? Вот у
тебе пример из го, фактори метод и DI
func NewUserService(db Database) *UserService {
return &UserService{db: db} // Injecting the dependency
}
Эм, почему это противопоставление? Вот у
тебе пример из го, фактори метод и DI
func NewUserService(db Database) *UserService {
return &UserService{db: db} // Injecting the dependency
}
>>14925 (OP)
Не помню ДДД, но каждой сущности свой репозиторий, который работает только с ней.
Это бизнес логика, её не должно быть в репозитории. Репозиторий нужен просто чтобы удобно получать и сохранять данные. А раз это бизнес логика, то её место в сервисе/контроллере.
Это уже область отчётов и построителей отчётов. Копай эту тему отдельно, там много разных тонкостей и подходов.
> 1) Это три репозитория по ddd, верно? И каждый должен работать только с соответствующей ей сущностью? ЮзерРепо не должен возвращать Заказ, а Заказ не должен отдавать продукт.
Не помню ДДД, но каждой сущности свой репозиторий, который работает только с ней.
> 2) Что делать если для оформления заказа мне надо обновить данные в нескольких репозиториях?
Это бизнес логика, её не должно быть в репозитории. Репозиторий нужен просто чтобы удобно получать и сохранять данные. А раз это бизнес логика, то её место в сервисе/контроллере.
> 3) Иногда бывает так, что для оптимизации прямые сложные запросы в БД дешевле чем через репозиторий. Допустим пример ...
Это уже область отчётов и построителей отчётов. Копай эту тему отдельно, там много разных тонкостей и подходов.
