Event Driven Programming : Identifying Events

In my last blog post, we took a more in-depth look at jQuery custom events to learn the specifics of how they're used. How, though, do you identify the events in your event-driven architecture? That's the subject of today's post.

Years ago, I had a conversation with a young programmer at a company I was consulting at. I had been speaking with the development group about crafting a robust architecture and the group was excitedly discussing architectural options -- all but one young man who remained silent.

After the group broke into smaller teams to work on a problem, I spoke with the unhappy programmer privately.

Me: Bill, you didn't participate in the discussion. Was there something wrong?

Bill: Yeah, seems like a waste of time. All this talk about architecture. We don't get paid to produce fancy diagrams; we get paid to write code.

Me: Ah, the code! Yes, without that, all we have are diagrams and specs.

Bill: Right! So then, why all this focus on the architecture? Yesterday, when you were working with us on actual code -- then I could see how that could help me.

Me: Yesterday, we got deeply into how to produce code right. Today, we're talking about how to produce the right code: that's what architecture is.

Bill: Maybe it's just not for me.

Me: But without a tangible architecture, how will you know what code to write? And if the architecture isn't robust, your code will be fragile -- no matter how well you write it.

Bill: (laughing) In that case, I guess we'll just rewrite it -- again. And that drives me crazy. We write the code, then things change and we have to rewrite the code. Sometimes before we get the first whack at the code done! That's how things are here.

Me: I understand. No time to do it right, but always time to do it over.

Bill: So, if that's going to be the way it is, let's not waste time on circles and arrows -- let's get going on the code.

Me: Perhaps the real problem isn't architecture. Could the issue really be bad architecture?

Apparently, he thought about this because over the next couple of weeks, he continued to ask me questions -- first privately, then with the group. Almost anyone who's had the chance to teach or mentor people has had the experience of the person who initially starts off disinterested (or even hostile) and ends up being a star. That was the case with Joe.

He decided that architecture was for him, after all -- and his group benefited from his growing expertise. Over the years, Joe and I have kept in touch and he's been the source of many interesting discussions as we thought together through some particularly thorny architectural question.

Architecture on an event driven program begins with identifying events. And there's no better place to identify those events than from the prototype. Let's say that Amazon has asked you to help them create an event driven architecture. They have a prototype printed out (as you requested). What do you do?

You take your highlighters and pencil and begin marking up the prototype. When you're nearly done with your first pass, it might look like this:

Now, you set about providing specifications for each numbered event:

1. 1_click_order
• product_id
• ship_urgency
• ship_address_id
• quantity
• is_gift_wrapped
2. add_to_cart
• product_id
• ship_address_id
• quantity
• is_gift_wrapped
3. add_to_wishlist
• product_id
• wishlist_id
4. add_to_shoppinglist
• product_id
5. payphrase_checkout
• product_id
• payphrase
6. info
• topic_id
7. create_payphrase
8. show_3d_party_sellers
• filter
• product_id
9. user_resell
• product_id
10. user_trade
• product_id
11. social_share
• product_id
12. author_details
• author_id
13. product_review
• product_id
14. join_student_program
15. share_image
• product_id
16. publisher_allow_search
• product_id
17. publish_for_kindle
• product_id
18. product_info_request
• product_id
19. kindle_reader

"There are only two hard problems in Computer Science: cache invalidation and naming things" – Phil Karlton

All programmers will agree that coming up with names -- for classes, methods, arguments, variables, etc. -- is, indeed, difficult. If you look at the event names produced by our first pass through the prototype, you'll probably notice that they suffer from lack of consistency. This is proof of Hal's Law: Your first attempt at naming will never be right. We must do what all good writers do: edit.

How shall we edit? We want to accomplish two things:

1. find a consistent pattern to our event naming
2. find logical groups that events can be placed into

The exact pattern isn't as important as its consistency and the logic of your group selection. Will you always include the group, then the action? Something like "Cart:Add"? How will you handle a request for some action (e.g. "add this item to my cart") v. the changed state of an application (e.g. "an item was just added to the cart")?

Naming may be -- no, is -- difficult, but the time you spend on getting it as good as possible will be repaid many times over as you and your team begin producing the code to create the application.

As you're deciding on event groups, you'll want to be aware of the fact that almost all of these events are going to require communication with the server. In fact, the groups you come up with are often going to be Controllers (in the Model View Controller) pattern.

In the next blog post, we'll look at integrating events with the code on the server.