Event sourcing architecture | OTUS
🔥 Что нужно, чтобы писать чистый код?
Курс «Архитектура и шаблоны проектирования». Спеццена для сдавших тест!
Подробнее

Курсы

Программирование
Flutter Mobile Developer Подготовка к сертификации Oracle Java Programmer (OCAJP)
-8%
Алгоритмы и структуры данных
-12%
Backend-разработчик на PHP
-8%
Web-разработчик на Python
-11%
Архитектура и шаблоны проектирования
-14%
Супер-интенсив «СУБД в высоконагруженных системах»
-18%
iOS Developer. Basic
-23%
Разработчик на Spring Framework
-23%
Python Developer. Basic
-16%
C# ASP.NET Core разработчик
-18%
Разработчик программных роботов (RPA) на базе UiPath и PIX
-6%
Highload Architect
-9%
React.js Developer
-12%
Android Developer. Professional
-7%
Software Architect
-12%
Программист С MS SQL Server Developer Cloud Solution Architecture Reverse-Engineering. Professional CI/CD Vue.js разработчик VOIP инженер Программист 1С Супер-практикум по использованию и настройке GIT Symfony Framework Супер-интенсив "Tarantool"
Инфраструктура
PostgreSQL
-10%
IoT-разработчик
-12%
Administrator Linux. Professional
-11%
Базы данных
-19%
Administrator Linux.Basic
-18%
Супер-интенсив «СУБД в высоконагруженных системах»
-18%
Супер-интенсив "SQL для анализа данных"
-16%
Highload Architect
-9%
MS SQL Server Developer Безопасность Linux Cloud Solution Architecture Разработчик голосовых ассистентов и чат-ботов Внедрение и работа в DevSecOps Администратор Linux. Виртуализация и кластеризация Нереляционные базы данных Супер-практикум по использованию и настройке GIT Супер-интенсив "Tarantool"
Специализации Курсы в разработке Подготовительные курсы
+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 комментариев
Для комментирования необходимо авторизоваться