Ануар Нурмаканов - Event Sourcing и CQRS на конкретном примере 

Отличный доклад. Просмотрел на одном дыхании.

Объяснил доступнейшим языком, спасибо!

Первый доклад по этой теме, после которого до меня прям много чего наконец-то дошло! Спасибо, Ануар )

класс доклад, спасибо )) интересно и позитивно ))

Ты просто красавчик! Спасибо огромное ! 😘😘😘😘

Отличный доклад и докладчик! Спасибо!

Докладчик просто бомба, разжевал очень хорошо.

В общем виде разделение записи и чтения в рамках реляционных субд решает репликация БД. Может не стоит трудиться со сложным Юнитом по синхронизации из видео. Проще применить репликацию.

Блин, на самом интересном закончилось

Отличный доклад!!! Про Бугаенко хорошо было)))

Автор упомянул перед вводом про CQRS и ES такую тему как DDD, с отсылкой как-будто это альма-матер... а потом показывает, как через сеттеры шатает агрегат в СОБЫТИЯХ :):):):)

в Амазоне нету Кафки, а чем Кинезис не подходит ?

Интересный вариант с кафкой, но я не совсем понял как будут решаться следующие проблемы если использовать кафку как event store: 1) Например мы добавили новую таблицу Materialized view, которая будет основана на уже существующих сообщениях и начинаем ее формировать и через кафку, нам придется прогнать миллиарды сообщения и обработать их, если например данные формировались несколько лет, возможно это вопрос к подходу, а не к кафке)) 2) Например, у нас есть сообщения в кафке, но они же не вечно там хранятся, ну например, если электричество отключат и так далее и упадут контейнеры, и с образом что-то случится, как нам восстанавливать данные? Ведь, как я понял, на жестком диске они хранятся в таком варианте, что их нельзя будет прочитать, ну или это считается плохим подходом.. Получается их нужно будет резервировать каждый раз в каком-то другом формате а потом как-то считывать 3) Порядок сообщений, ведь в кафку сообщения могут падать в беспорядочном виде, а нам нужен будет например другой порядок, наверное это как-то решается на уровне приложений.. Но все таки? Например, в обычных бд можно сортировать хотябы по id или по другому полю потом считывать в порядке. 4) Как я понял нельзя считывать данные с определенного id, а например у нас уже есть materialized view до определенного id и нам нужно его обновить. В любом случае хотелось бы понять best practice для kafka. потому как многие рекомендуют его как event store

Ануар, молодец, очень хорошо смотришься на сцене. Правильный слог, интонация и боди language

Хороший доклад. Почему не сделать трансляцию из дискусионного зала? Уверен, там тоже полезная информация была.

"Мессадж броукер" - этим все сказано

Я фронтендер. Не могу отлелаться от мысли, что докладчик просто описывает redux с таймтревелом в немного видоизмененных терминах.

доклад огонь. но про производительность mv такое себе.

24я минута «Событие знает как себя применить к агрегату». Кажется все должно быть наоборот - Агрегат слушает события и решает что из них к себе применить.

С удовольствием посмотрел картинки и меме. Жаль голос на их фоне постоянно отвлекает. А если серьёзно - отличный доклад, огромное спасибо за работу. Но назвите меня скучным и занудой, но моё личное скромное имхо - количество смешнявок перечёркивает весь труд.

Спасибо за интересное видео, но Киев пишется как Kyiv

Я так понял Kafka streams уже решает всю ту магию с базами и ентитями. Агрегация и прочая дич

Везде пример конференции... Может сам кто то что то придумаеет?

Афтар отжог нипадецки

Очень интересных доклад, спасибо докладчику! Взял для себя очень много пищи для размышлений.

В конце была интересная дискуссия, жаль что перебили.

То что тут названо "обработчик" на 27:45 - в общепринятой терминологии называтся "Projector", а "материализованное представление" - "Projection"

Я конечно понимаю что докладчик старался, но эти шуточки больно слушать... И зачем вводить в заблуждение о том что такое CQRS? Это всего лишь разделение команд от запросов, при этом можно писать/читать в одну и ту же базу, в одни и те же таблицы. То что можно выделить для запросов отдельные представления (даже отдельные базы построенные на другой парадигме) для увеличения производительности - это уже деталь, это не необходимое условие CQRS. И еще вагон других вопросов по откровенно базовым понятиям...

Ne znaju... ja skorei bi ispolzoval protocol buffers v mesto JSON dlja hronenie i obmena mezhdu servisami. Legche parsitj i menshe mesto nado. Na samom dele prijatno videtj shto u kovo to takaja zhe arhitektura. :)

ИМХО Event Sourcing который хранит изменения это головная боль, мягко говоря. Что если схема изменится - название поля, тип .т.д., что делать со старыми записями обновлять - охренеешь от багов, оставлять как есть - зачем этот мусор вообще нужен. Суть ES это не git, просто нужно записывать каждый раз новую копию и не париться. Автор я думаю сложные системы никогда не строил, судя по обилию явных ошибок и поверхностных рассуждении, просто впиливает в проекты модные фичи. Чего ещё в принципе ждать от работников епама.)

Мы использали JsonIgnore..., мы использали JsonIgnore... пипец) что это за фундаментальная шутука такая, видимо что-то из CS, и доступно только для продвинутых jзеров :) Вообще у автора в голове полная каша, лучше бы сделали простые MVC формы. При таком то уровне зананий стыдно выступать с докладом.