Перейти к содержанию

Повествования, основанные на хореографии.

Хореография — способ реализации повествований, когда участники подписываются на события друг друга и реагируют соответствующим образом.
Сперва рассмотрим пример — повествование createOrder().

Пример: повествование CreateOrder

Оптимистичный путь:

Pasted image 20210919120040.png

  1. Сервиc Order создает заказ с состоянием APPROVAL_PENDING и публикует событие OrderCreated.
  2. Сервис Consumer потребляет событие OrderCreated, проверяет, может ли заказчик размещать заказы и публикует событие ConsumerVerified.
  3. Сервис Kitchen потребляет событие OrderCreated, проверяет заказ, создает заявку с состоянием CREATE_PENDING и публикует событие TicketCreated.
  4. Сервис Accounting потребляет событие OrderCreated и создает объект CreditCardAuthorization с состоянием PENDING.
  5. Сервис Accounting потребляет события TicketCreated и ConsumerVerified, выставляет счет банковской карте заказчика и публикует событие CreditCardAuthorized.
  6. Сервис Kitchen потребляет событие CreditCardAuthorized, меняет состояние заявки на AWAITING_ACCEPTANCE.
  7. Сервис Order потребляет событие CreditCardAuthorized, меняет состояние заказа на APPROVED и публикует событие OrderApproved.

Неудачный путь

Предположим, авторизация банковской карты завершилась неудачей.
Pasted image 20210919125828.png
1. Сервиc Order создает заказ с состоянием APPROVAL_PENDING и публикует событие OrderCreated.
2. Сервис Consumer потребляет событие OrderCreated, проверяет, может ли заказчик размещать заказы и публикует событие ConsumerVerified.
3. Сервис Kitchen потребляет событие OrderCreated, проверяет заказ, создает заявку с состоянием CREATE_PENDING и публикует событие TicketCreated.
4. Сервис Accounting потребляет событие OrderCreated и создает объект CreditCardAuthorization с состоянием PENDING.
5. Сервис Accounting потребляет события TicketCreated и ConsumerVerified, выставляет счет банковской карте заказчика и публикует событие CreditCardAuthorizationFailed.
6. Сервис Kitchen потребляет событие CreditCardAuthorizationFailed, меняет состояние заявки на REJECTED.
7. Сервис Order потребляет событие CreditCardAuthorizationFailed, меняет состояние заказа на REJECTED.

Как мы видим, участники взаимодействуют в стиле “издатель/подписчик”.

Надежное взаимодействие на основе событий

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

Преимущества

  • Простота. Сервисы публикуют события при создании, обновлении и удалении бизнес-объектов.
  • Слабая связанность. Участники подписываются на события, не владея непосредственной информацией друг о друге

Недостатки

  • Сложность для понимания. В отличие от оркестрации хореография не описывает повествование одним участком кода — его реализация разбросана между сервисами. Из-за этого может быть сложно понять, как работает то или иное повествование.
  • Риск возникновения циклических зависимостей.
  • Риск жёсткого связывания.
Последнее обновление : 22 мая 2023 г.
Дата создания : 26 июля 2022 г.

Комментарии

Комментарии