В разделе по БД, стоит ли делать вьюхи (материальные и обычные)? Насколько они могут ускорить время ответа и когда их стоит и не стоит создавать?(например, материальные нужно синхронизировать чтобы были актуальные данные, поэтому их не получится использовать в системах где эти данные часто меняются, какие еще есть случаи?)
Добрый день! Cогласен со всеми замечаниями, однако хочу добавить:
CQRS/ES — это инструмент для специфичных сценариев, где важны: Полный аудит и трассируемость изменений, Сложная бизнес-логика с частыми изменениями правил, Гибкость в создании новых представлений данных, Приемлемость получения данных с задержкой проекций (Eventual Consistency)
Для высоконагруженных сценариев вроде аутентификации можно использовать гибрид: ES для "долгой" логики (заказы, платежи) + CRUD/кэш для "горячих" путей (сессии, профили).
P.S. Если проект не требует этих преимуществ — действительно, проще обойтись CRUD операциями. ES добавляет сложности, которые должны окупаться бизнес-требованиями.
Да, вы правы! Первый вариант с Kafka делает приложение stateless.
Раньше приложение было stateful, но с Kafka: состояние переносится в очередь – A просто принимает сообщения и отправляет их в Kafka, не заботясь о маршрутизации.
В разделе по БД, стоит ли делать вьюхи (материальные и обычные)? Насколько они могут ускорить время ответа и когда их стоит и не стоит создавать?(например, материальные нужно синхронизировать чтобы были актуальные данные, поэтому их не получится использовать в системах где эти данные часто меняются, какие еще есть случаи?)
Добрый день!
Cогласен со всеми замечаниями, однако хочу добавить:
CQRS/ES — это инструмент для специфичных сценариев, где важны: Полный аудит и трассируемость изменений, Сложная бизнес-логика с частыми изменениями правил, Гибкость в создании новых представлений данных, Приемлемость получения данных с задержкой проекций (Eventual Consistency)
Для высоконагруженных сценариев вроде аутентификации можно использовать гибрид: ES для "долгой" логики (заказы, платежи) + CRUD/кэш для "горячих" путей (сессии, профили).
P.S. Если проект не требует этих преимуществ — действительно, проще обойтись CRUD операциями. ES добавляет сложности, которые должны окупаться бизнес-требованиями.
Да, вы правы! Первый вариант с Kafka делает приложение stateless.
Раньше приложение было stateful, но с Kafka: состояние переносится в очередь –
Aпросто принимает сообщения и отправляет их в Kafka, не заботясь о маршрутизации.Спасибо за замечание! Поправлю статью.