#events #architecture #chatbot #serverless #serverless-architecture
#Мероприятия #архитектура #чат-бот #бессерверный #бессерверная архитектура
Вопрос:
Кажется здравым смыслом, что скрытие команд (т. Е. триггеров для таких действий, как вызов бессерверной функции) в событиях является антишаблоном. Применение шаблона событий для взаимодействия с пользователем (событие: «пользователь нажал кнопку X») кажется вынужденным и на самом деле не работает в многоканальных приложениях (скажем, веб-приложениях и потоках диалога в чатах).).
В «традиционных» приложениях со стандартными пользовательскими интерфейсами действия пользователя, такие как нажатие кнопки, приводят либо к прямому вызову службы, либо к направленному асинхронному сообщению. Но каков архитектурный шаблон в бессерверной настройке, если мы
- не знаете, какая функция или служба в моей текущей настройке отвечает за выполнение действия?
- возможно, существует несколько реализаций, и пользователи должны выбрать наилучшего кандидата в диалоговом пользовательском интерфейсе? (механизм Android для обработки намерений, например, для открытия PDF-файла, и у вас установлено несколько средств просмотра)
В настоящее время я думаю о компоненте (либо настроенном, либо самообучающемся), который подписывается на намерения пользователя (с контекстом) в виде широковещательных сообщений и может сопоставлять их с действиями (которые после запуска запускают хореографию событий). Но, возможно, уже есть проверенные фреймворки или шаблоны, которые я не смог найти, потому что я просто не нахожу правильных слов.
Комментарии:
1. Я не уверен, о чем вы спрашиваете, но вас может заинтересовать шаблон доски. Он использует реестр служб для отделения источников событий от потребителей событий. См. docs.osgi.org/whitepaper/whiteboard-pattern/020-background.html
2. Спасибо.. Разделение источников и потребителей (шаблон доски OSGIs, брокеры событий или даже более мощные системы, такие как Google Pub / Sub), безусловно, необходимо. Но события — это неизменные вещи из прошлого, интересно, как мы могли бы применить концепцию архитектуры, управляемой событиями, к действиям pub / sub intendet (то, чего мы хотим достичь в будущем)