If you live in Austin, Texas in the early fall of 2017, and happen to work for HomeAway, when you search for “domain events” on Google, you might get something like this:
So then, according to Google, the following must be a “domain event”:
Haha. Funny. An “event” at “The Domain”. A Domain Event. Clever.
Seriously speaking, the third Google search result above for “domain events” lands you here: “Domain Event — Martin Fowler”
Two things to notice.
- The simplicity of the definition,
- and the date (2005).
If you read what Martin Fowler had to say on the subject, he thought way back then that this was something worth investigation and further inquiry, especially with respect to a concept called event sourcing (note the date is still 2005). However, until very recently, he left it alone for the most part (I may be wrong and would humbly welcome the correction if this is not historically accurate).
Now, I believe, is the time to resurrect this concept and apply it holistically across the enterprise, especially as it pertains to analytics. When implemented holistically, I believe, many analytics that historically required batch, ETL, and possibly days to calculate, can often be performed in near real time, bringing value quicker to end-users, reducing turn around time, and possibly impacting user behaviors as we collectively build systems of engagement and beyond.
Microservices are eating the world
If 2014 was the year for “big data”, it seems that 2017 is the year of “microservices” buzz. There’s even a meme for it.
All joking aside, Josh Evans from Netflix gave this excellent overview of microservices at Netflix (don’t watch it… really!! Don’t watch it… Ok. You’ve been warned). Amazon Web Service’s Adrian Cockroft has also given numerous presentations on the topic.
For the purpose of this post, here is Adrian’s definition of a microservice:
or, more succinctly, a microservice is a “domain-driven bounded context”.
We can all probably agree on this diagram.
Microservice Architecture focuses on domain-driven bounded contexts that enable loosely coupled, independently deployable services. An interesting corollary is that, as a result, these bounded contexts are also observers of subjects that may have state. Specifically, they observe the state of their respective domains.
Microservices as stewards of “domain state”
If microservices observe their domains, then a natural name that emerges is a “domain event”.
“If a microservice is a domain-driven, independently deployable bounded context, then observed events related to that domain are naturally called, domain events.”