САМАЯ УЖАСНАЯ ПРОБЛЕМА CRUD. РЕШАЕМ ЧЕРЕЗ EVENT SOURCING
HTML-код
- Опубликовано: 10 апр 2022
- Андрей Иванов - Питон
Используйте мою ссылку в криптобирже OKEX и получите -10%:
www.okx.com/join/PYTHONANDREY
Мои курсы на UDEMY: www.udemy.com/user/andrey-iva...
Пожертвования: www.donationalerts.com/r/pyth...
Github: github.com/knucklesuganda
Telegram канал: t.me/pypapyrus_ru
Другие Видео по Python: ruclips.net/user/playlist?list...
Канал на английском языке: ruclips.net/channel/UCeC9...
Поставьте лайк и подпишитесь!
#Python #Питон #программирование #programming
Я вам скажу, как человек который разработал и использует в бою ES/CQRS фреймворк, автор видео не разобрался с темой. То, что автор заявляет как "проблема CRUD`a", проблемой не является, это решается через аудит лог, например, через запись историй транзаций, что вообще-то норма, т.к. цепочку переводов иногда нужно откатить, поэтому последовательность движения денег сохраняется в финансовых системах всегда и безо всякого ES. Так же обращение к инфраструктурному слою реализации ES для решения бизнес-задач, является конкретным говнокодом, в ES системах мы не имеем права обращаться к подсистеме восстановления состояния модели из Application или Domain слоев, нельзя загрузить состояние "на дату", кое где за это даже бьют и нередко ногами. "Проблема CRUD`a", в кавычках, потому что это не всегда проблема, в анемичности моделей, например мы создаем модель "User" интернет-магазина и пытаемся заставить ее работать во всех вариантах использования, это у нас и клиент магазина, получатель доставки, автор сообщений на форуме, комментатор, автор отзыва и клиент поддержки, и.т.п. Как результат модель анемична, смотря на нее мы не можем сказать каково ее предназначение, что конкретно она моделирует. Другое дело конкретные бизнес-модели, которые сразу тебе говорят, я клиент поддержки и ничего более, да в системе клиент поддержки создается по событию регистрации пользователя(очень условный пример) и может в т.ч. менять свои аттрибуты по событию изменения адреса доставки модели получателя доставки, но она точно моделирует бизнес-объект и не пытается быть всем для всего.
Как можно заметить источником состояния моделей являются бизнес-события, поэтому очень удобно хранить состояние модели как последовательность событий и восстанавливать его из этой последовательности при применении изменения состояния(обычно тоже событием), пусть вас не путает мой пример, модель клиента поддержки не состоит из событий пользователя и получателя доставки, эти события "провоцируют" изменения состояния собственными событиями клиента поддержки. И это, CRUD не противопоставляется ES, CRUD противопоставляется доменным бизнес-моделям, их можно реализовывать без ES (чаще так и бывает, собственно говоря), ES - это паттерн сохранения состояния, вполне можно CRUD модель хранить с помощью ES, но никто так не делает, поскольку тот кто дорос до ES, прекрасно знают что к чему ))).
Это лишь верхушка айсберга, там еще очень много всякого про согласованность в конечном счете, оптимистичные блокировки, агрегаты, снапшоты, саги, DDD, слоистые архитектуры, полное низвиржение роли БД и проч. К тому же это все довольно сложно в реализации и в настройке производства ПО используя эти подходы, хотя идея звучит довольно просто. Можно потихоньку почитывать, но нырять с головой в это не стоит. Это точно не является серебрянной пулей, это можно использовать или в богатых на бизнес-логику моделях или в системах с большим потоком бизнес-событий. Короче это настолько не Junior/Middle тема, здесь такие высокие требования к стратегическому проектированию, что не стоит даже начинать засирать народу мозги. Достаточно лишь немного задуматься хотя бы над проблемой версионирования событий в подобной системе, чтобы понять бесперспективность обсуждения этих подходов в рамках 17-ти минутного видео, я целую книгу прочитал по теме версионирования событий, и даже она не смогла внятно расписать бест-практис, куча трейд-оффов в кучке подходов. Можно еще поугорать и попросить реализовать глобально-уникальное значение, например email пользователя, у тех кто пытается это освоить с попытки осознания этого вопроса начинают шестеренки из головы выпадать.
Я бы рекомендовал начать с изучения слоистых архитектур - луковая, гексогональная, порты и адаптеры, чистая. После того как вы поймете как абстрагируется инфраструктура, в чем различие доменного слоя от слоя приложения, что такое контракты по интерфейсу и инъекция зависимостей, научитесь строить агрегаты, познаете применение иммутабельных инвариантов, value-object, команды/запросы/собыия и их шины, познаете проблемы соглассованности данных в распределенных системах и как это все вместе работает - можно начинать приступать к синхронному CQRS, потом к асинхронному, ну а потом вы будете чуть-чуть готовы пообсуждать ES и его внедрение в ваш продукт.
Скажите что вы архитектор пожалуйста, а то у меня все больше синдром самозванца развивается после таких комментариев
@@ilyaponomarev9279 Синдром самозванца лечится чтением книг, разбиранием чужого кода и реализацией сложных задач. Я не архитектор, т.к. то о чем я говорю с точки зрения архитектора - просто блоки для решения задач, ему достаточно знать свойства и риски применения технологии.
Пример странный. В чём проблема хранить в бд записи о зачислениях и отчислениях денег, как делают все банки? Не понятно.
К тому же хотелось бы увидеть реализацию этого творения в реальном коде, а не кликбейтные слова о том, что crud мёртв
А вообще, круто, что делаешь обзоры на всевозможные паттерны проектирования, но хотелось бы конкретики
Даёшь пример реализации на простом python проекте, как организовать структуру и вообще всю эту схему в коде, как хранить ивенты и пр.
А там "Ну, поднимите зукипер и кафку" пушто без них понадобится хранить ивенты либо в состоянии шо пиздец, либо в бд, что является простым журналированием запросов и придётся ещё писать какие-нибудь ручки, чтобы повторять запросы по ид. Но этим никто заниматься не будет пушто проще на фронте нажать кнопку заново (на его диаграммке изображён человечек, так что можно предположить, что это про фронт), а в более сложных системах используется вот зукипер.
Хотелось бы увидеть это на практике. Можно ли реализовать EVENT SOURCING через SQLAlchemy ?
Один вопрос , откуда ты такую инфу находишь?
Называется стэк вызовов
Стоит начать с того , что крипта в принципе работает по принципу блок чейн, и там нет возможности потерять записи ;(
Никто не уделяет этому внимание, а ведь это одна из важнейших деталей в проекте.
PS: Хотелось бы увидеть кодовый детальный пример.(Где хранится, как хранится, как достать и тд)
Спасибо за видео-уроки.
Так а кто мешает рядом вести аудит?
Или нам тут рассказывают, что агрегаты, рядом с которыми можно вести аудит - отстой, а аудит с подсчитанными агрегатами - супер?)
А вообще, event sourcing - это больше про организацию асинхронного взаимодействия с возможностью реализации "отложенной" согласованности данных в большом количестве сервисов (согласованность в конечном счёте), что является противоположностью классических синхронных транзакций. При чём здесь CRUD вообще?
Так, а в чём в итоге самая ужасная проблема круда?
Круд это просто классификация rpc вызовов: CREATE READ UPDATE DELETE. Если внедряем CQRS, то просто текущее состояние не возвращается сразу после выполнения модификаций, но сама классификаия RPC вызовов никуда не денется)
Ну а как уж ты будешь эти команды исполнять - дело личное, бэкэндерское. Хоть в очередь их запихивать, хоть в кафку
Так что я тут не вижу ни проблемы, ни то, как ES или CQRS могли бы заменить круд
Зато ивент сорсинг добавляет множество проблем, например если мы вернули саксесс на команду сразу после получения, query может вернуть старые данные в случае, если используется ивент сорсинг. Так что если для круда используется не буферизированный канал, тогда нужно держать соединение открытым пока не получим гарантию того, что изменение применилось, нужно добавлять таймауты внутри приложения и следить за соблюдением sla
Так что внедрять ивент сорсинг только потому что это каефненький паттерн бессмысленно. Это довольно дорого в обслуживании, разработке и смысл будет иметь только в специфических кейсах
А вот если сразу же внедрить в приложение CQRS без самого ивент сорсинга, т.е. без асинхронного взаимодействия, тогда это позволит заложить на будущее возможности внедрения ивент сорсинга