Юра
Ну так и скажи что у меня актив рекорд
Юра
И все
Юра
Флаш кругом
Юра
Просто в транзакции оберни
Павел
Актив рекорд vs datamaper
Павел
А ты говоришь за UoW
Юра
Напиши сервис который инкапсулирует работу с бд вообще и всё
Павел
UoW и в активрекорд можно воткнуть, просто не глобальный
Юра
И пусть он там что угодно делает главное чтобы это быдо по возможности атомарно
Павел
Ну точнее на апдейт)
Юра
Представь как бы это делал если мы у тебя было два микросервиса один с эластиком другой с мускулем и сделай
Dmitry
Если бы были бы разные флашеры для каждой сущности - это лучше ложится
Если в одном юзкейсе больше одного хранилища и флашера, то это сразу хана транзакционности. Так что даже развивать эту тему нет смысла.
Юра
Ну не хана, просто совсем другой подход
Павел
Если в одном юзкейсе больше одного хранилища и флашера, то это сразу хана транзакционности. Так что даже развивать эту тему нет смысла.
Тема о том, что контракт единого флашера архитектурно выглядит херней, имхо.
Грубо, какая то штука которая сбрасывает состояние всех репозиториев в базу.
Dmitry
Ну не хана, просто совсем другой подход
Если не в отдельных модулях или микросервисах, то хана при любом подходе
Юра
Но теперь у тебя две базы, эластик может упасть отдельно от бд и ты жто долен предусмотеть
Юра
Чтобы не сидеть ночами с фикс скриптами
Юра
Просто херак туда херак сюда не прокатит
Павел
Тема о том, что контракт единого флашера архитектурно выглядит херней, имхо.
Грубо, какая то штука которая сбрасывает состояние всех репозиториев в базу.
Пример - у нас 2 юзкейса, которые вызываются подряд в контроллере, почему нет.
В одном например мы флаш не вызвали.
А во втором вызвали.
Почему флаш второго хэндлера сбрасывает данные первого в БД?
Юра
У тебя долден быть один сервис
Dmitry
Тема о том, что контракт единого флашера архитектурно выглядит херней, имхо.
Грубо, какая то штука которая сбрасывает состояние всех репозиториев в базу.
Фигнёй выглядит тема работы с двумя агрегатами в одном юзкейсе.
А если агрегат один и флашер один, то всё равно, где находится этот один флашер.
Юра
И контроллер не должен решать что и когда ему флашить значит
Юра
Не знаю. Выглядит пока как архитектурная проблема
Юра
Все эти флаши и разные репозитории
Павел
Фигнёй выглядит тема работы с двумя агрегатами в одном юзкейсе.
А если агрегат один и флашер один, то всё равно, где находится этот один флашер.
Да, только Юра говорит про атомарность и главный плюс - сохранение двух агрегатов в одной транзакции без прямого вызова транзакции
Юра
А нельзя хранить все в мускле а в эластике дополнительные данные?
Юра
Намного упрощает
Юра
Зачем заказы в эластике?
Юра
Это вообще не база данных так-то
Юра
Это обёртка над люсен индексом для полнотекстового поиска
Павел
А нельзя хранить все в мускле а в эластике дополнительные данные?
Все можно, я просто привел пример с эластикой, что если мы будет писать свой репо без доктрины, то не будем писать свой uow и скорее всего буде OrderRepository::save контракт
Павел
И тут вопрос, почему у нас одно add + flush() а второй save()
Юра
И тут вопрос, почему у нас одно add + flush() а второй save()
Потому что разные способы хранения?
Кирилл
Знаете парни
Павел
Потому что разные способы хранения?
ДА не должно приложение зависеть, инвесия зависимостей.
Пишем приложение без базы вообще сначало на моках
Кирилл
Вы выделавыетесь друг перед другом
Павел
Или на inmemory
Кирилл
Не более
Павел
у нас будет inmemory флашшер?
Dmitry
Да, только Юра говорит про атомарность и главный плюс - сохранение двух агрегатов в одной транзакции без прямого вызова транзакции
Вы имеете в виду только агрегат, но суть сложнее.
Главный плюс - это транзакционное сохранение всего состояния системы (агрегат, его события, идентификатор команды для идемпотентности) единым внешним флашем, чтобы не потерять данные и не записать мусор.
Юра
Парень спрашивает просто почему у него в случае с реляционный субд add плюс save а в случае с эластиком просто save
Юра
Не знаю что тут сказать
Павел
Вы имеете в виду только агрегат, но суть сложнее.
Главный плюс - это транзакционное сохранение всего состояния системы (агрегат, его события, идентификатор команды для идемпотентности) единым внешним флашем, чтобы не потерять данные и не записать мусор.
А какая разница в вашем примере будет save внутри репо или в флашере. Мы говорим сохрани весь агрегеат
Павел
Павел
@zim_it вот мы пишем приложение, еще не знаем какую БД будем сипользовать. Как мы решим на какую будет save а на какую add?
Павел
Может у нас все приложение будет в эластике
Павел
А может все в мускуле
Павел
Может с доктриной, а может нет
Юра
@zim_it вот мы пишем приложение, еще не знаем какую БД будем сипользовать. Как мы решим на какую будет save а на какую add?
Я напишу интфрейсы без всяких save и add
Юра
Ты же сам говоришь приложении не зависит от персиста
Юра
И тут же пишешь save
Юра
Тестируй сервис который сохраняет
Павел
Я напишу интфрейсы без всяких save и add
Так выходит от персистенса зависит будет ли в коде save или add+flush
Юра
Ну блин стандартная тема с ДТО и сервисом
Юра
Дал сервису дто и сказал createOrder
Павел
Ну блин стандартная тема с ДТО и сервисом
Причем тут dto и сервис, если это чатсь контракта приложения
Павел
Дал сервису дто и сказал createOrder
Так внутри сервиса будет репозиторий использоваться либо репозиторий + flusher
Павел
Какие контракты будем писать на этапе отсутсвия БД?
Юра
У тебя в чём вопрос? Как замокать БД?
Юра
Все я молчу
Юра
Мож кто посоветует что-то
Юра
Твой вопрос сводится к вопросу в чем разница между add add add flush и add flush add flush add flush
Павел
Павел
Ты мне пытаешься за симфони, я тебе за архитектуру
Павел
Поэтмоу и проехали)
Юра
Сделай begin add flush add flush commit и все. Будет у тебя один контракт
Юра
В архитектуре ты не особо шаришь раз атомарность тебя не сильно волнует
Павел
Я завожу тему про контракт, ты про атомарсность и симфони - мы о разных вещах говорим
Юра
Контракт разный у разных БД
Юра
Так понятно?
Юра
Если тебе нужен один контракт, пишешь адаптер. Адаптер призван подвести олин контракт под другой
Павел
Инверсия зависимостей
Юра
Инверсия зависимостей не меняет контракт