Можем ли мы действительно использовать Event Sourcing и CQRS, архитектуру, управляемую событиями, для воронки электронных покупок?

Question

Допустим, у Checkout есть следующие услуги:

1. Служба заказа, создание заказа, сбор и доставка, оплата и оформление заказа, а также управление жизненным циклом заказа.

2. Служба инвентаризации, обеспечивает доступность продукции.

3. Служба доставки, предоставляет варианты доставки и расходы

4. Профиль клиентасервис, предоставляет информацию о клиенте.

5. Кредитный сервис, авторизация платежа

6. Служба бронирования делает бронирование

Ниже описан процесс создания заказа:

Заказ создан, пользователи предоставляют адрес доставки, рассчитываются варианты доставки, оплата взимается, заказ размещается и пользователю показывается подтверждение.

Многие из проверок ритейлеров являются синхронизацией и управлением сервисом заказа.

Скажем, если мы используем источник события, CQRS и хранилище событий, сервис заказа создает событие заказа и сохраняется в хранилище событий, публикуемсобытие домена и все другие службы подписались на хранилище событий, так как им необходимо обновить параметры доставки, стоимость доставки, оплату за завершение заказа и использование CQRS для информирования пользователя о статусе каждого шага, который он должен просмотреть.

Я пытаюсь понять:

насколько сложным будет приложение оформления заказа со всеми событиями домена, такими как добавление адреса доставки, резервирование, выбор варианта доставки, добавление платежа и выполнение заказа?

Будет ли это быстрее, чем синхронизировать работу службы заказов, организовав запрос на оформление заказа?

Будет ли согласованность в случае сбоя?Как обращаться с вечной последовательностью?

Answer 1

Ну, мы можем использовать Event Sourcing и CQRS для процесса проверки.Как вы сказали, вы будете поднимать события, и подписанные сервисы будут реагировать на это.Насколько сложным или простым не является вопрос, стоит ли это в вашем случае?Event Sourcing и CQRS - сложная модель со многими преимуществами, но вам нужно правильно ее реализовать.

Для возможной последовательности вам, возможно, придется полагаться на Saga Pattern, где в случае неудачи вам придется поднять компенсационное действие для отката.