Алексей Зимарев - Event sourcing in a long run
ฝัง
- เผยแพร่เมื่อ 3 ต.ค. 2024
- Подробнее о конференции DotNext: jrg.su/3WmFRE
- -
В настоящее время event sourcing находится на волне популярности, и много копий было сломано в жарких дискуссиях вокруг этой, казалось бы, не очень сложной идеи. Специалисты из компаний с громкими именами публикуют статьи, описывая свой путь и опыт применения паттерна, но немногие из них действительно отражают оригинальные идеи, сформулированные Грегом Янгом 15 лет назад.
В этом выступлении Алексей хочет вернуться к сути того, что такое event sourcing в контексте Domain-Driven Design, почему он полезен для определенных типов систем, чего обычно опасаются люди в отношении паттерна и как избежать распространенных ошибок.
Отличный доклад, а оформление и структура слайдов вообще 10/10.
Спасибо за доклад! Частенько натыкался на ответы Алексея по MassTransit - за них тоже благодарен.
Где можно посмотреть ответы на вопросы, которые были в «дискуссионке» в Zoom?
Почему класс Order не наследуется от абстрактного класса Aggregate но при этом использует его методы?
Отличный доклад!
Спасибо.
я живу в новой зеландии ? замутим что нибудь!
Не под все отчеты подходит такой подход. Известно, что отчеты имеют настроечные фильтры и отчет строится на лету по этим пользовательским фильтрам. Поэтому неразумно строить и содержать огромное множество гипотетически востребуемых отчетов (read- моделей) под все комбинации настроек фильтров.
Это же типичный компромисс память vs время. Для уменьшения кол-ва памяти требуемой для отчётов можно их не хранить совсем, генерируя на лету. Но время на получение отчёта вырастет.
Спасибо за хороший доклад!
Делают потому что программирование превратилось в элитную профессию где математику ваообще не преподают на должном уровне (институты сокращают расходы на образовании! капиализм! бизнес! ничсего больше). Вы можете представить успешно работающих разработчиков с тройками по математике или 2 йками??? Я таких видел полно!!!! 10 миллионов программистов не пониамющие матиматику вообще!
Я согласен насчет EF ... Другие не понимют что использовать ADO намного проще чем работа с реальным EF на профессиональном уровне в production!!! Поэтому если не знаете и не профессионал никогда не используете EF. EF можно только после полной кастомизации его включая выноса EF в отдельнный проект DATA! Только при сценарии code firts и используя богатую модель (DDD), рефакторинг, IoC, fluentAPI, fluent mapping & validation, automapping, etc.... Использованаие всех этих технологий - намного сложней чем работать с ADO... Никогда не пользуете Dataannotations in EF,
Я тоже делю данные в БД, самостоятельно 12 лет без всякой помощи. И очень громко ржал когда мне кто нибудь рассказывает про нормализацию даных! таким научным языком! Только я подругому называю! У меня четыре базы views(витрины), сервисы, operational, reporting!
Насчет репозитория тоже согласен. К тому же repos услодняют код до нельзя !!!
Код тоже неплохой но окнечно его можно доработать и получиться еще лучше
С вами практически повсем позициям согласен
А почему так мало просмотров?
Очень профессиональный доклад. Мне ваш доклад нравиться болше чем Мартин Фаулера (Martin Fowler)! Русские действительно лучшие!!! ...