Обработка исключений и контроль состояния в архитектуре, управляемой событиями

Question

Я много читал о шаблоне проектирования событийно-управляемой архитектуры (EDA), и, хотя он кажется исключительно мощным (смеет ли я видеть красивым?), Я запутался в двух вещах: во-первых, как управлять условной логикой, и в двух Как контролировать исключения.

Допустим, я хочу разработать какой-нибудь обратный вызов для использования Ajax. Обратный вызов будет запущен интерфейсом с "именем пользователя" и "паролем", и я верну локализованный "код возврата", указывающий на успех или неудачу.

Когда пользователь успешно войдет в систему, давайте предположим, что я зарегистрировался, отправил управление и электронную почту и начал сеанс. Если бы я использовал шаблон на основе EDA, у меня могло бы быть следующее:

Вход пользователя в систему -> (отправляет событие, всегда) -> (Журнал, отправка электронной почты, запуск сеанса все вызываемые)

То есть обратный вызов входа в систему отправит некоторое уведомление, выдающее все зарегистрированные классы, прослушивающие это конкретное событие. Моя проблема в том, кто подтверждает , что пара аутентификатора (имя пользователя, пароль) успешна? В некотором смысле эти три события действительны, только если аутентификация была правильной.

Поэтому, возможно, тогда я сначала запускаю одно событие, и только в случае успеха запускаю другие:

Вход пользователя в систему -> (Всегда отправляет событие) -> Попытка войти в систему пользователя (Событие отправляет, если оно прошло успешно) -> (Журнал, отправка электронной почты, все сеансы вызваны)

Пока это работает, я потерял контроль над тем, как получить обратную связь. Похоже, что события следуют ходу мыслей "поставил и забыл"; как я могу вернуть код в интерфейс? То есть, я не вижу возможности для наблюдателя событий дать отзыв на эту тему.

Это продолжает обработку исключений; Как лучше всего обрабатывать исключения в этом сценарии?

Цени любой совет! Адриан

(Хотя это, вероятно, не имеет значения в теоретическом смысле, я пытаюсь применить это к PHP)

Answer 1

EDA - это здорово, но это не значит, что вы должны использовать его ВЕЗДЕ в любом случае. Цель EDA состоит в том, чтобы обеспечить развязку и масштабируемость, что достигается за счет отсутствия немедленной обратной связи и возможности согласования.

Также, по крайней мере, в веб-приложениях, лучше, чтобы EDA была реализована как архитектура событий домена, то есть эти события сообщают, что произошло нечто, связанное с доменом (бизнесом).

Вы правы в том, что события относятся к типу "запускай и забывай", потому что они выражают что-то в прошлом, опубликованном, чтобы другие заинтересованные компоненты были уведомлены. Но загвоздка в том, что эти компоненты ничего не знают о других компонентах или источнике события. Помните, дело в отделении.

Вход пользователя в систему и тому подобное не являются действиями в домене, и их намного проще и удобнее поддерживать "старым" способом. И хотя вам нужна некоторая развязка, речь идет скорее о низком уровне, чем об архитектурном (высоком) уровне развязки.