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 — универсальный и идеальный способ построения всех подобных приложений (кстати, а что значит "подобных"?). Разумеется, нет. У всего есть свои плюсы-минусы и область применения.

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