В свое время я использовал термин сообщение. Сообщения я разделял на несколько типов: событие, команда, запрос. Событие предполагает описание того, что что-то случилось (например, заказ создался) и не требует наличия получателей. Передача события происходит по принципу "получатель-подписчик" и по своей природе асинхронна. Команда — это требование к системе произвести какое-то действие. Пример команды — создай заказ. Посылка команда может быть как синхронной(дождемся успешного результат или ошибки) так и асинхронной. Принципиальное отличие команды от события, это то, что нам должен быть известен получатель команды. Запрос — синхронен по своей природе, т.к. мы ожидаем ответа. Пример запроса "дай мне информацию о заказе N12". Во многих случаях разделение между запросом достаточно условное и лежит скорее в семантической плоскости.
Согласно этой модели, компонент системы мог подписаться на события, мог опубликовать интерфейс для посылки ему команд и запросов.

Читая статьи на тему event driven архитектуры, заметил, что избегается использование термина message(сообщение) — используется только термин event(событие). Сейчас вот задумался, как описать в терминах события три вышеназванных операции над системой, если в качестве

Проинформировать всех о том, что заказ создался — здесь все остается без изменений.
Создать заказ — можно решить следующим образом. Компонент, который отвечает за создание заказа сидит и ожидает событие "Информация для создания заказа готова". Это событие генерируется, например, формой для создания заказа.
Получить информацию о конкретном заказе — тут тоже можно выкрутиться двумя событиями. Первое "Кто-то хочет получить описание заказа N12" и "Описание заказа N12 сформирована".

Два последних варианта выглядят крайне бредово. Если мы говорим, что event driven парадигма распространяется только на первый случай, то полбочки меда разбавляются полбочкой дегтя, особенно в случае распределенных систем. ИМХО, последователи ориентированного на события подхода вынуждены комбинировать эту парадигму с классическими подходами. Или, возможно, что надо просто "научиться мыслить событиями", а мои мозги просто закоснели и не могут взглянуть на мир по-новому.

С точки зрения SOA — последние два пункта решаются красиво, т.к. именно для решения этого класса задач SOA и предназначена. Мы можем запросить сервис создания заказа, можем запросить сервис получения описания заказа(или фабрику заказов) или просто сервис для работы с заказами. Где этот сервис живет и как он реализован — мы не знаем и знать не хотим. Но SOA не предполагает удобного механизма для управления событиями. Можно конечно ввести сервисы EventSubscriptionService, EventPublishService и т.д. . Но, это, ИМХО, будут жалкое подобие на возможности чистого event driven подхода с фильтрами, триггерами, раутерами...


Вот такие мысли вслух. Немного несвязно, но, надеюсь, что мне удалось обозначить проблему. Что может сказать по теме уважаемый all?