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

Question

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

Предположим, я хочу спроектировать некоторый обратный вызов, открытый для потребления Ajax. Обратный вызов будет запущен передним концом с «именем пользователя» и «паролем», и я верну локализованный код возврата, указывающий на успех или неудачу.

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

Журналы пользователей В -> (событие Отправки, всегда) -> (лаг, Отправить на e-mail, Start Session все называется)

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

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

пользователя в -> (событие Отправки, всегда) -> Попытка входа в систему пользователя (Отправки случае, если успешный) -> (Log, Send Email, Start Session all called)

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

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

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

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

Answer 1

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

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

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

Вход в систему и т. Д. Не являются действиями в домене, и это намного проще и удобнее для реализации их «старого» способа. И в то время как вы хотите развязать, это больше о низком уровне, чем об архитектурном (высоком) уровне развязки.