В спецификации Pact для асинхронного обмена сообщениями потребителями являются службы, которые читают сообщения, и провайдеры, которые пишут эти сообщения.
Как описано в разделе Пакт сообщений и команда Шаблон этого сообщения в блоге, который хорошо работает для сообщений, которые являются своего рода Событием. Эти сообщения интересуют множество потребителей, и они их потребляют. Но не подходит, когда сообщения представляют собой команды.
Однако, если мы рассмотрим шаблон распределенных команд, команды сериализуются как сообщения, которые асинхронно вызывают другие службы. Команды обычно нацелены на службу, известную вызывающему компоненту. Вместо брокера сообщений, на который могут подписаться несколько служб, команда помещается в очередь, которая регулярно опрашивается получателем.
В этом сценарии отношение к создателю сообщения как к провайдеру кажется нелогичным. Вместо этого создатель сообщения использует функции получателя команд. Это похоже на шаблон запрос-ответ, но асинхронный и без ответа, поскольку нет обратного канала через очередь.
Это похоже на сообщения запроса:
Запросы описывают запрос информации или состояния. У запроса может быть несколько обработчиков. При отправке запросов клиент указывает, хочет ли он получить результат от одного или от всех доступных обработчиков запросов.
Службы, содержащие обработчики запросов, будут ожидать сообщений с запросами. С точки зрения Пакта, они будут потребителями. Если эта информация интересует разные службы, необходимо написать тест потребителя для каждой службы, желающей получить данные.
Я не вижу реальной проблемы со всем этим, но меня беспокоит, что такие инструменты, как can-i-deploy или конвейеры CI, имеют предположения о вариантах использования, о которых я не знаю.
Кто-нибудь знает больше по этой теме? Есть какие-то проблемы, о которых я не знаю? Я буду использовать Pact для JVM и Axon Framework & Server, но я чувствую, что это что-то связано со спецификацией Пакта.
Большое спасибо.
