Events are awesome

Posted by Dru Sellers on September 8, 2009

“I find that services are much more composable when they emit events rather then send requests.
Since this way the coupling between services is reduced”
Arnon

I really like this statement because, well its what I am working on, but also because it talks about events as a first class thing. I have been enjoying thinking about my current company in this light.

All business action has an external stimulus. Something happens outside the company, and this causes the company to do something. A customer calls or the market shifts, either way something happened and now you need to react. I like to think of these as events, and as such I have decoupled the event itself from the system that wants to respond to it. In the past the event would have been embedded in the system, flipping this around means multiple systems can respond to the ‘exact’ same business event. Neeeeeaters. :)

This is why integration via events is just so much easier.

I have also started to think about what it would mean to develop a system ‘event first’, and then you can look at what needs to be done when these events happen. It builds completely different systems, based on some initial drawings.

-d

About Dru Sellers

Sr. Software Engineer at Dovetail Software.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://jonathan-oliver.blogspot.com Jonathan

    That’s what Greg Young’s approach is all about–making domain events explicit (first-class citizens) in your domain model.

  • http://www.bradleyboveinis.com Brad

    I took the leap to event driven architecture a while ago. I never want to go back :) . I’m really loving Udi’s implementation of the Domain Events Pattern/handlers. I’m building it into our CE device application.

  • Daniel Lemos Itaboraí

    The problem of using events everywhere is that it makes harder to know what’s happening with your application as a whole. For an example, imagine that you have a Create Purchase Order event and there are 5 event handlers for this particular event. The third handler, when fired discover some inconsistencies that weren’t detected earlier(for whatever reason) and fires a Cancel Purchase Order event, what would be the correct way to handle the two previous fired handlers and the two yet unfired ones? What to do when some sort of ordering must be established between event handlers and what would be the appropriate way to enforce this ordering?

    I think, over time, complex handlers can become invisibly coupled through the changes that they propagate through the application state. My gut feeling is that these event handlers are interstitial things that all too often tend to be overlooked.

    Despite that, I think system events are a great thing when

    A) they are applied at the right granularity level (which I believe to be something close to a handler per system module involved);

    B) you disallow dynamic subscription to events (I think dynamic subscriptions are as evil as computed goto’s) and

    C) you always keep event subscriptions together, whether on a configuration file, script or in a database table.

  • Eyston

    Agreed. This stuff is great. Udi and Greg both have great information out there on this topic. I’m writing a side project on my own time just so I can try this stuff out!

  • http://thinkbeforecoding.com Think Before Coding

    @Daniel> That’s what Sagas are done for, orchestrate conversations and provide potential compensation when things fail.
    The problem of events handled by several services is managed by defining clear bounded contexts.
    Each bounded context react to the event in its particular context (shipping, billing, customer relationship etc.) It makes things clear.

  • Sean

    Udi’s post may interest you… Domain Events – Salvation: http://www.udidahan.com/2009/06/14/domain-events-salvation/