Повествования на основе оркестрации¶

Оркестрация как способ реализации повествований предполагает выделение оркестратора, единственной задачей которого является рассылка инструкций участникам. Оркестратор взаимодействует с участниками в стиле ”команда-асинхронный ответ”. Чтобы выполнить этап повествования, он шлет участнику командное сообщение, указывая, какую операцию нужно выполнить. После выполнения операции участник возвращает оркестратору сообщение с ответом, которое оркестратор обрабатывает и решает, какой этап повествования нужно выполнить дальше.
Пример на картинке. Обратите внимание, оркестратор здесь — класс в сервисе Order.

Имеет смысл моделировать оркестратор в виде конечного автомата, который описывает все возможные сценарии. Например, для повествования createOrder()

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

• Упрощенные зависимости. Оркестратор вызывает участников, но участники не вызывают оркестратор. В результате оркестратор зависит от участников, но не наоборот, поэтому циклических зависимостей нет.
• Меньше связывания. Каждый сервис реализует API, вызываемый оркестратором, поэтому ему не нужно знать о событиях, публикуемых другими участниками.
• Улучшенное разделение ответственности и упрощенная бизнес-логика. Вся координирующая логика находится в оркестраторе, поэтому доменные объекты становятся проще — им не нужно знать о повествованиях, в которых они участвуют.

Недостатки¶

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

Комментарии

Комментарии