Event sourcing architecture | OTUS
⚡ Подписка на курсы OTUS!
Интенсивная прокачка навыков для IT-специалистов!
Подробнее

Курсы

Программирование
C++ Developer. Professional JavaScript Developer. Professional Android Developer. Professional Microservice Architecture React.js Developer JavaScript Developer. Basic PostgreSQL Программист С C++ Developer. Basic Team Lead PHP Developer. Professional Подготовка к сертификации Oracle Java Programmer (OCAJP) Алгоритмы и структуры данных Разработчик IoT C# Developer. Basic Unreal Engine Technical Game Design C# ASP.NET Core разработчик Python Developer. Basic Архитектура и шаблоны проектирования Node.js Developer iOS Developer. Professional Cloud Solution Architecture Kotlin Backend Developer Agile Project Manager Scala-разработчик Symfony Framework iOS Developer. Basic Супер-интенсив Azure Специализация Python Developer
Инфраструктура
Экспресс-курс по управлению миграциями (DBVC) Экспресс-курс «IaC Ansible» Microservice Architecture Разработчик программных роботов (RPA) на базе UiPath и PIX Внедрение и работа в DevSecOps NoSQL Специализация Administrator Linux
-24%
Разработчик IoT Мониторинг и логирование: Zabbix, Prometheus, ELK MongoDB
-37%
DevOps практики и инструменты MS SQL Server Developer SRE практики и инструменты Administrator Linux. Advanced Infrastructure as a code Супер-интенсив "Tarantool" Специализация Network engineer
Корпоративные курсы
Экспресс-курс по управлению миграциями (DBVC) Экспресс-курс «IaC Ansible» Разработчик программных роботов (RPA) на базе UiPath и PIX Внедрение и работа в DevSecOps NoSQL Spark Developer Экспресс-курс «CI/CD или Непрерывная поставка с Docker и Kubernetes» Game QA Engineer DevOps практики и инструменты Enterprise Architect Node.js Developer Cloud Solution Architecture Agile Project Manager Супер-практикум по работе с протоколом BGP Infrastructure as a code Промышленный ML на больших данных Супер-интенсив Azure Руководитель поддержки пользователей в IT
Специализации Курсы в разработке Подготовительные курсы Подписка
+7 499 938-92-02

Event sourcing architecture

Давайте представим приложение для учета складских остатков в интернет-магазине. Есть некий товар. У товара есть остаток, допустим, 10 единиц. На склад могут привести новую партию этого товара — 5 единиц, и новое значение остатка станет 15 единиц. Товар могут продать, допустим, 3 единицы, тогда остаток станет 12. Получается, что у нас есть целое число (остаток) и две операции: одна увеличивает это число, вторая уменьшает.

Это не что иное, как классическое CRUD-приложение, т. е. приложение, которое выполняет операции: создание (Create), чтение (Read), модификацию (Update), удаление (Delete).

Добавляем какую-нибудь базу данных, пользовательский интерфейс, и все готово, приложением можно пользоваться.

Очень быстро пользователя такого приложение не устроит текущее значение остатка товара, он захочет знать значение остатка на заданную дату. Такой функционал сделать не сложно.

Сейчас у нас есть форма ввода, допустим, поступления новой партии. В этой форме пользователь вводит сколько товара привезли и нажимает "ввод". Программа берет это число и выполняет примерно такую операцию:

update остаток = остаток + сколько_товара_привезли where id = id_товара

Мы хотим знать остаток на заданную дату, для этого в дополнение к update выше добавляем insert, который вставит в таблицу истории дату и остаток на эту дату. В этой таблице будет ответ, сколько было товара на заданную дату. Это проверенный временем надежный и простой подход.

А что, если при поступлении новой партии надо запустить какую-нибудь дополнительную процедуру?

Например, надо уведомить клиентов, что появился товар, который они ждут. Для простоты будем считать, что такое уведомление будет сделано "мгновенно". Решение просто и очевидно. Рядом с insert в таблицу истории добавится запуск такой процедуры. Это проверенный временем надежный и простой подход.

Магазин развивается и постепенно наша функция обработки поступления товара обрастает все большим и большим функционалом. С которым становится весьма сложно справляться.

Какая может быть альтернатива?

Есть и другие варианты, например, event sourcing architecture. При этом подходе поступление товара мы представляем как событие? и наше приложение превращается в конвейер обработки таких сообщений.

Что это дает?

Во-первых, мы прямо "из коробки" получаем историю изменения, т. е. теперь это не "костыль с боку", а полноценный "встроенный в ядро" функционал. Пробежав, по этой истории мы можем выдать ответ на заданную дату, включая текущее значение. Погодите, но ведь теперь для получения текущего значения надо сделать намного больше действий!

Будет медленнее! Да, но и тут есть нюансы...

Во-вторых, мы можем разрабатывать новые обработчики событий, причем обработчики могут быть максимально независимы. Это упростит командную разработку и тестирование.

В-третьих, мы можем значительно проще сделать асинхронные обработчики событий. Понятно, что "мгновенно" очень мало что делается. События позволят упростить выполнение долгих процедур.

Event sourcing architecture — универсальный и идеальный способ построения всех подобных приложений (кстати, а что значит "подобных"?). Разумеется, нет. У всего есть свои плюсы-минусы и область применения.

Поговорим об этом на открытом уроке.

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться