2

I've been reading up a lot about the event driven architecture (EDA) design pattern, and while it appears exceptionally powerful (dare I saw beautiful?) I'm confused about two things: one, how to control conditional logic, and two, how to control exceptions.

Let's say I want to design some callback exposed for Ajax consumption. The callback will be fired by the front end with a "username" and "password", and I will return a localized "return code" indicating success or failure.

When a user successfully logs in, let's assume I log it, send management and email, and start a session. If I was using an EDA based pattern, I might have the following:

User Logs In -> (Dispatches event, always) -> (Log, Send Email, Start Session all called)

That is, the login callback will dispatch some notification issuing all registered classes listening to that particular event. My problem is, who is confirming if the authenticator pair (username, password) is successful? In some sense, these three events are only valid if the authentication was correct.

So, perhaps then I fire one event first, and only if successful, fire the others:

User Logs in -> (Dispatches event, always) -> Attempt to log in user (Dispatches event, if successful) -> (Log, Send Email, Start Session all called)

While that works, I have lost control of how to obtain feedback. Events appear to follow the "set and forget" train of thought; how can I return a code to the front end? That is, I cannot see a way for an event observer to give feedback to the subject.

This continues to exception handling; how is the best way to handle exceptions in this scenario?

Appreciate any advice! Adrian

(While it probably doesn't matter in a theoretical sense, I'm attempting to apply this to PHP)

AdrianGW
  • 143
  • 1
  • 8

1 Answers1

3

EDA is great but it doesn't meant you should use it EVERYWHERE in ANY case. EDA purpose is to provide decoupling and scalability and that is achieved with the trade off of not having immediate feedback and dealing with eventual consistency.

Also at least in web apps, it's best that EDA to be implemented as a Domain Event Architecture, that is those events communicate that someting related to the domain (business) has happened.

You're right that events are a 'fire and forget' type, because they express something in the past, published so that other interested components would be notified. But the catch is those components don't know anything about other components or the source of the event. Remember, the point is decoupling.

User login and such aren't domain actions and it's much easier and maintainable to implement them the 'old' way. And while you want some decoupling, it's more about low level than about architectural (high) level decoupling.

MikeSW
  • 16,140
  • 3
  • 39
  • 53
  • Great, thanks so much Mike. I think I came to the same conclusion myself, that this was not a "one size fits all" type of pattern. Is it true saying that focusing EDA to the business domain only is called Domain EDA? – AdrianGW Jan 31 '14 at 11:48
  • It's not called anything. But if you say Domain Events pattern people understand what you mean. – MikeSW Jan 31 '14 at 12:42