In the business world, Event Sourcing is essentially keeping track of all important events that happen within an organization in the order of occurrence and never modifying these events. The good part is you can probably keep your current database structure while still putting these event streams into place. The idea is that an event (typically defined as a small class of primitive types) is published by one system and any other system can subscribe to these events and act on them if needed. For example, let’s say we are developing a new consumer web site and a new customer sets up an account through a web page. As part of the process in persisting the customer data, an event is also published telling others that there is a new customer in the system. Some other business processes that might want to know about this new customer are a communications system that perhaps sends out a welcome email and another process that starts the aggregation of data to help fit our web site to the customer’s interests and profile they just entered during signup.
Three good reasons event streams are good for business:
1. Audit Trail
2. Easier Setup for Testing
3. Human readable sequence of business events
In my mind, it’s easiest and best understood to create software systems that model the world we live in. Events are occuring all around us constantly and all at the same time. We can’t go back and change the past; instead we react to these events and create new events to change things the way we want.
By using an Event Source on customer events, it is simple to look up events by customer number in the order they occurred. Having these events makes functional testing much easier. By having an input of one event, the assertion on the outcome of that event applied to some business process code becomes much easier. By having these events available and assuming you’ve defined your Ubiquitous Naming among all of the business, then walking through scenarios and making new Gerkhin Format test cases should be a lot easier.
Here’s a few links to people in industry that have either created/coined some of these names and patterns or are well-versed in their design and implementation details.
I’ve been working on a book the past year or two and it’s been a slow-going process. At the moment the name is ‘How to Build an Event-Driven Enterprise System’ and I’ve got it up on leanpub. If you’re interested, please sign up for updates on the site and I’ll start pushing out sample copies as they are available.
How to Build an Event Driven Enterprise System
Thanks for listening,