Рассмотрим следующий сценарий из архитектуры LMAX, описанного Мартином Фаулером:
Для иллюстрации я буду использовать простой пример без LMAX. Представьте, что вы делаете заказ на драже с помощью кредитной карты. ‹...>
В архитектуре LMAX вы бы разделили эту операцию на две. Первая операция будет собирать информацию о заказе и завершаться выводом события (запрос подтверждения кредитной карты) в компанию, выпускающую кредитные карты. Затем процессор бизнес-логики будет продолжать обработку событий для других клиентов, пока не получит событие, подтвержденное кредитной картой, в своем входном потоке событий. При обработке этого события он будет выполнять задачи подтверждения для этого заказа.
Таким образом, заказ хранится в памяти до тех пор, пока не будет получен результат обработки платежа.
Теперь давайте предположим, что вместо этапа обработки кредитной карты у нас есть этап, который занимает гораздо больше времени, например: нам нужно выполнить инвентарную проверку, где кто-то должен физически убедиться, что у нас есть заказанный вкус драже. Это может занять час.
Если это так, не приведет ли это к увеличению данных, хранящихся в памяти, потому что потенциально много заказов будет ожидать события обновления состояния запасов?
Возможно, в таком сценарии нам нужно удалить заказ из памяти и включить его как часть выходного события, внешняя система (инвентарь) отвечает за генерацию другого входного события, которое включает детализацию заказа.
Проблема, которую я вижу в этом подходе, заключается в том, что мы не можем включить инвентаризацию как часть процессора бизнес-логики.
Мысли о том, как мы справляемся с этим?
