Domain Event Driven Architecture

While working on my presentation for Qcon London 2010, I came to the following conclusions:

  1. SOA is all about dividing domain logic into separate systems and exposing it as services
  2. Some domain logic will, by its very nature, be spread out over many systems
  3. The result is domain pollution and bloat in the SOA systems

Domain EDA: By exposing relevant Domain Events on a shared event bus we can isolate cross cutting functions to separate systems

  • SOA+Domain EDA will reduce time-to-market for new functionality
  • SOA+Domain EDA will enable a layer of high-value services that have a visible impact on the bottom line of the business

Here is the full presentation:


15 thoughts on “Domain Event Driven Architecture

  1. Unfortunately i wasn’t at qcon so i’ve only seen your slides.
    I don’t know if the following is an off topic question…

    What do you think is the relation between EDA and AOP?

    • Hi Carlo,
      I guess one way to think of Event-driven Architecture (EDA) is that it is a form of AOP for Enterprise Application Integration (EAI). AOP is something that is typically used within one piece of software to address intra-application cross-cutting concerns (such as logging or security). EDA is an architectural pattern to integrate different applications in an enterprise, and hence require some form of transport bus and contract.


  2. HiStefan,

    Your idea of taking SOA a level-up is thought provoking. Thanks for the idea. In your presentation when you referred to one sub-system publishing event to the event bus is it some kind of a standard event (a kind of protocol) that has the meta-information about the event or a domain specific event along with the entity that participated in the event. I would want to go ahead with a reference implementation because from theory it seems like this approach solves lot of puzzles faced by the white label solution providers.

    Thanks & Regards
    Suresh Reddy

  3. Hi Suresh,

    Thanks for the feedback. We use a messaging infrastructure based on ActiveMQ, but we have a custom EDA-client JAR that encapsulate that detail from a producer and consumer point of view. We use the Protocol Buffers format for the messages.

    I hope that answers your question.


    • Hi Stefan,
      I understood that point. I am in a dilemma as to what an event message should carry. one option is to send all the information related to the event as an event message (using protocol buffer) or just send the meta information as an event message (like id’s or references) and use a shared database/persistence layer.

      Thanks & Regards
      Suresh Reddy

      • Hi Suresh,
        Sorry for the late response. I’d recommend using data in the payload.
        Otherwise its going to scale poorly if there are many consumers.


  4. Hm i always wonder how data queries are realized in such environments. Events change state – fire and forget etc. However, your (Web) UI needs data to show.

    • Hi André,
      In my experience, many things that are outside of the core domain of the user-case that initiated the transaction.
      For example “Register Customer” may require a “welcome email” or a “background check”. Some things may have to be done synchronously while the customer is waiting (for feedback), but many use-cases can be deferred and hence the logic can be moved to another system AND be fired on the event “New Customer” for decoupling and performance.

      Hope that helps,

      • Sorry, my question was not accurate. Putting things off the critical path or introduce asynchrony as you describe it, is known to be helpful here 🙂 As message publishers don’t need to know all the message receivers you gain decoupling and performance (if asynch). Constructing the user interface however requires to know the different data sources (customer contact info, customer x, customer y, customer validation results, …), that is, coupling. Do you live with all the 1:1 component to component-coupling here? Commands are event-driven, Queries are ?

  5. Hi Stefan,

    What your view on implementing EDA in an enterprise that uses lots off-the-shelf (COTS) applications. We could choose the applications that buy in the future but have many existing apps that may not understand the publish-subscribe model. Should we create wrappers for these? Also, what are the challenges that you see in implementing EDA in an enterprise? What kind of technology maturity that we expect from the enterprise?


    • Hi Bala,
      Yes, I’d recommend a bridge to integrate with the EDA. The bridge app can be using an API in the COTS or even use a db table or a file as a hand-over point. Consider looking at Camel if you’re a Java shop for these types of apps.
      Regarding EDA in a bigger enterprise I’d say that the main challenges are around is governance and evolving the messages (which need to be considered to be contracts of course).

  6. Stefan,

    Very interesting presentation, thanks for sharing it. Ironically my project uses a good bit of EDA but not enough SOA which causes problems with tasks that need to be done synchronously. This has lead to developers pulling external event driven services into a monolithic application rather than simply making a synchronous service call.

    One of the items we’re struggling with is how to store data in an SOA + EDA combination. We have multiple applications sharing one DB right now which causes a number of performance and flexibility issues. I’m thinking about splitting the DB into silos per service but I worry about the traditional replication/stale data problems. How do you handle this in your system and do you use the domain events to synchronize across multiple data stores?


  7. Hi Stefan

    Thanks for your inspirational blog!

    Do you have any examples, like a EDA project of a smaller scale, that can illustrate how the domain objects are broken up? I have started redesigning the EDA I had, which has a lot of if-then-else statement and request-response focused instead of truly event driven.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s