Vasily
На чтении?
Vasily
Плюс при подобном подходе update и delete не реализуют
Vladyslav
на всю операции с чтением и записью
Vladyslav
а где удаляет? а почему нет update? новая запись если обновилось?
Doge
я, конечно, лучше всего понимаю C#
А ок, у меня где-то валялся пример как раз на C#, но он с эмуляцией HKT, сейчас попробую в обычный вариант переделать.
Vasily
То, что я рассказываю, называется event sourcing
Vladyslav
А ок, у меня где-то валялся пример как раз на C#, но он с эмуляцией HKT, сейчас попробую в обычный вариант переделать.
если не сложно, то и меня призови, если будешь скидывать)
Vasily
Обычные круды лепить, конечно, не очень получится
Vladyslav
обычных крудов обычно мало)
Vasily
Но от них всегда можно отказаться
Vasily
Лично я считаю, что орм этц - тяжёлое наследие трудного детства. Как психологическая травма
Vladyslav
какие альтернативы?
Vasily
Ну для начала определиться, что требуется
Vasily
От данных
Vasily
Какие сценарии работы с ними
Vladyslav
типичное бизнес приложение
Vasily
Показать данные на формочке,отредактировать, сохранить
Vasily
По факту- редактирование конфигурации бизнес процесса
Vasily
Которую обычно кладут в реляционную бд и натягивают на нее бизнес модель
Vladyslav
Да, так а какая альтернатива орм в таком случае
Nikolay
Как жить, когда у тебя 69 джоинов и 130 полей? :D
Nikolay
Запросы только больно писать
Nikolay
По 400+ строк
Vasily
А потом, когда исторические данные хранятся с рабочими, наступает жопа
Vladyslav
Да там по идее то нечему лагать, если настроить индексы и всё такое
Утверждение сильное, но проверять я его, конечно, не буду)
Ayrat
Как жить, когда у тебя 69 джоинов и 130 полей? :D
Это то самое тяжёлое наследие. Микросервисы на евентсорсинге гибче, быстрее до прода доезжают. Но с ними другие проблемы - версионирование евентов, дебаг и мониторинг.
Vasily
Какой-то менеджер нажал кнопку быстрый поиск по транзакции и система встала раком
Vasily
Случай реальный, если что
x
Это то самое тяжёлое наследие. Микросервисы на евентсорсинге гибче, быстрее до прода доезжают. Но с ними другие проблемы - версионирование евентов, дебаг и мониторинг.
микросервисы же предполагают отдельную мелкую базку для каждого сервиса, да?
Vasily
Ayrat
микросервисы же предполагают отдельную мелкую базку для каждого сервиса, да?
Там базка только для восстановления нужна. А так можно все через кафку гонять
Nikolay
Это то самое тяжёлое наследие. Микросервисы на евентсорсинге гибче, быстрее до прода доезжают. Но с ними другие проблемы - версионирование евентов, дебаг и мониторинг.
Да тут хрен знает как в микросервисы завернуть
Nikolay
Все данные связаны и выгребаются одним запросом
Nikolay
Ну завернёшь тут в микросервисы, лучше не станет
Nikolay
У тебя просто запрос будет выполняться в микросервисе
Nikolay
🤷♂️
Vasily
Станет
Ayrat
Конечно станет
Ayrat
Только быстро
Ayrat
Он же уже имеет готовый Стейт для ответа, все ж собрано
Nikolay
Всё же упирается в базу
Ayrat
Это ж евентсорсинг
x
Это ж евентсорсинг
т.е. на нашем игрушечном примере с миллиардом юзермейлов: мы имеем не юзермейлы, а ивенты их добавления, изменения, удаления? как это спасает?
Ayrat
Ты делаешь микросервис для запроса. Например - зп сотрудников за год. Он слушает евенты изменения зп и меняет стейт свой постоянно. Или нет, поменяет по первому запросу и заснапшотит
Ayrat
Nikolay
Vasily
Ну ебашь сложный
Vasily
Ща зарешаем
Ayrat
Микросервисы и пр решают проблемы скалирования, добавляют других. Но скалирование там космическое.
Ayrat
А евенты убирают связанность. Можно вообще любую логику делать. Тот же набор евентов может быть сагрегирован в разные стейты
Nikolay
Есть документ, у него может быть несколько версий, каждая версия передаётся разным сотрудникам, и каждый сотрудник его может менять, при этом пока документ у одного сотрудника, он будет неизменным у другого сотрудника, когда один сотрудник передаёт документ обратно другому сотруднику, нужно накатывать эти новые изменения, я отображать новый документ, и это всё в рамках одной версии документа.
Если создаётся новая версия документа, предыдущая блокируется, но доступна для просмотра.
Это верхний слой, потом эта лапша вся идёт сильно дальше
Ayrat
В бд все обычно гвоздями друг к другу прибито
Nikolay
Выезжаем за счёт полного логирования всех действий, и записи меток передачи
Vasily
Ну тут event sourcing спасет
Ayrat
Ну гит тип на евентсорсинге в виде распределенных комитов живёт же ж. Почему нельзя сделать для каждого документа актор (микросервис) который будет следить за своей инвариантностью?
Ayrat
Тут идеальный кейс вообще
Vasily
И я о том
Nikolay
Я думаю, если это делать на ивентах, быстро запутаешься
Vasily
Нет
Ayrat
Это просто по-другому
Nikolay
И опять же, требования постоянно меняются
Vasily
Запутаешься как раз в 130 полях
Nikolay
Грубо говоря, у нас до этого было одно поле, а теперь оказалось, что его нужно разделить на два поля, и как быть в данном случае с ивент сорсингом?
В базе я просто добавил новое поле, и руками все данные перенёс
Ayrat
И опять же, требования постоянно меняются
Это самое крутое в евентсорсинге. Смена требований означает другую логику агрегации. А евенты те же
Ayrat
Ayrat
Допустим у тебя набор евентов - Васе повысили зп на 1к. Штук 5 таких в стриме.
Первые требования отображать среднюю ЗП за последние 3 месяца.
Ок собрал, посчитал, показал.
На следующий день, а ещё надо среднюю за карьеру.
Ну ладно, передеплоил сервис (один, а не всю базу) он начал с тех же евентов другой стейт получать с двумя полями
Ayrat
Изи
Nikolay
Васе повысили ЗП на 1.5к, из них 500 это премия, а 1к оклад, и нам нужно все данные, которые до этого были разделить на премию и оклад
Nikolay
Как быть?