MadeByMonsieur

“It’s really become clear to me in the last couple of years that we need a new building block and that is the Domain Events”
– Eric Evans, QCon 2009

During the last years I have been lucky to be part of teams creating different Service Oriented Architectures (SOAs) in different sizes and environments. Some of the projects were very successful, some were a bit less. The power of SOA is widely known and there is a lot of information about it in “the Internet” so I won’t be going too deep in that. Instead, I will write about the problems I found in SOA and how Domain Event Driven Architecture (Domain EDA) came to help.

I think a word of caution is in place here before reading forward: I’m still very, very junior in SOA and specially in Domain EDA so I’m not even claiming of being a professional in this. I’m still learning new every day (sadly most of the time from my own mistakes) and love to discover and experience more. So specially when you don’t agree, I would love to hear some feedback and counter arguments.

Ok, back in business.

While working on the SOA projects I started to feel that the SOA is missing something. Maybe because my inexperience but still the SOA implementations most of the time ended up looking nice only on paper. The CEO/CTO guys were happy but if you looked deeper into the services, the systems included all kind of ugly hacks and shortcuts that were usually done due a lack of time. So something was wrong when it was not possible to implement “beautifully” new systems and services in the speed the marketing was expecting.

But thanks to (a very big special thanks to) Stefan Norberg’s and Eric Evans’ presentations I found Domain Event Driven Architecture (Domain EDA). As monsieur Norberg puts it, Domain DEA really completes SOA and gives it the boost it needs.

I will try to explain using a use-case why I think SOA can get slow and messy and how this problem could be solved using a Domain Even Driven Architecture.

Our use-case is about a value added service company called VASC (completely fictional) which already has a very nicely built SOA architecture:

As we can see in the above diagram, the company has everything build in nice SOA with autonomous services like reporting, billing, CMS, etc. Everything runs nicely and individual services can be replaced pretty painlessly without having to effect the company’s main business. The business people of VASC are happily planning their next big campaign and product launch. The IT department is happy because they can do their geegy stuff  with individual services without halting the whole production and evolution and messing with the business people.

But one day the CEO hits her fist to the table and wants to implement an “affiliation system”. The VASC is doing a lot of TV, radio and Internet advertising and want to know which campaigns are successful and which just eats the money. This is what they want to use the “affiliation system” for.

So the Architect of the company gets to work. The Architect needs to change the front-end to catch some data. He needs to track the user through the systems to finally get the information to the reports the Big Boss needs. The CEO also wants that they are able to know four hours after the ad campaign has started if the campaign is showing sign of being successful or not. This of course brings even more grey hair for the Architect since the way their DataWareHouse works – a batch is run once or twice a day to get the data to the warehouse and then build the statistics.

The Architect gasps when he realizes that to implement the new service he needs to implement changes to all of the following services despite the beautiful SOA they had so hard worked for:

Even the VASC’s architecture is “proud to have” SOA, they would end up changing almost all the services to be able to implement a one new feature. Implementing it and launching it is most unlikely to be the fastest and funniest process. Not even talking about all the endless meetings that needs to be done to spread the information what and why. The Architect takes a whiskey and wonders with a serious face – “man gotta do what man gotta do”.

When the Architect proposes his plans to his colleagues he starts to wonder why don’t they have all that information they need already available in “real time”? From where users came to the VASC’s web pages? What did the users buy , when, how, etc. That all is business information the business people are the most interest of. Why it’s not available in real time but only available in the reports coming from the famous DataWareHouse they spend a fortune to? If he would have the mentioned information available in real time, the “affiliation system” would have been a joy to create. And fast.

And then, in the middle of the sentence the Architect realizes: the information he needs are the events the services do which are important for the Business People.

Hallelujah! Mazel Tov! Heureka (plus all the other words) the Architect yells! Every service must yell out loud the events of the actions they do!

The Architecture decides to change his systems to just publish the events they do and makes the new affiliation system to subscribe to these event. Every service can be updated independently and the development of the new affiliation system can start immediately.

That night the Architect had a whiskey with a smile in his face thinking of all the possibilities the implementation of Domain Event Driven Architecture had brought to him.

So, let’s end our story and see what kind of events VASC’s architecture could send:

Now based on the events above, the new affiliation system can be build as a separate service that just needs to subscribe to the relevant events above. The nature of the events is “fire-and-forget” so publishing the event will not really effect the way the existing services works at all. They “just fire-and-forget” the business relevant events that occurred and continues the job.

So that’s it. What do you think?

---

This was my first blog post about Domain Event Driven Architecture and there are many to come. The next post will be about how I have implemented Domain Event Driven Architecture using XMPP and how the “fire-and-forget” events can be easily published.

If you want to learn more about Domain EDA, I recommend to watch a presentation called Event Driven-Domain Architecture by Stefan Norberg. It’s very good presentation and gives you more information and examples why Domain EDA is just so great. Stefan and his college also presents a different solution how to implement Domain EDA than I’m going to present in the coming weeks.

–
tuomas@madebymonsieur.com