While working on my presentation for Qcon London 2010, I came to the following conclusions:
- SOA is all about dividing domain logic into separate systems and exposing it as services
- Some domain logic will, by its very nature, be spread out over many systems
- 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:
Advertisement
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.
/Stefan
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
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.
Thanks,
Stefan
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.
/Stefan
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,
Stefan
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 ?
Hi Stefan,
Thank you for the post and all your presentations about Domain EDA. It has motivated me for months now and finally I have started to blog about it too. My first blog post can be read here: http://weblog.madebymonsieur.com/why-domain-event-driven-architecture/
Thanks once again!
Hi Tuomas,
I’m happy to hear!
Thanks for the kind words. I’ll be sure to check out your blog!
Stefan
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?
Thanks,
Bala
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).
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?
Thanks,
-mike