Go Back to the Future with Event Sourcing and CQRS
Event Sourcing is an approach to building software with a long track record of success. By placing business concepts at the heart of our code, we can decouple systems into small services that can be quickly built, changed, and replaced. Although Event Sourcing has been around for many years, it remains outside the mainstream paradigm of software development–much to our detriment.
With Event Sourcing, we place the highest value on the simple capture of essential business events without attempting to interpret them. We can then relegate all interpretations of those events to subsystems that are easy to build, change, and replace when necessary. The resulting systems have single responsibilities and are decoupled from each other, which makes them simple to modify. Event Sourcing can enable us to move faster by supporting rapid experimentation with new perspectives, new user interactions, and new insights into our business.
Event Sourcing is agnostic of technology stack and language style, but it goes well with another pattern called CQRS: Command Query Responsibility Segregation. In this talk, we will do a deep-dive into both of these two patterns and discuss:
What is Event Sourcing, and how does it differ from systems designed around current state.
Interpreting Events into denormalised projections for very fast reads (Queries).
Receiving and validating Commands that, if successful, result in new Events.
Single responsibility services for reacting to Events by creating other events and, if necessary, triggering external behaviour.
We will cover the advantages of the pattern, to give us an idea for when and why it makes sense to use it. But it isn’t a silver bullet, and we will also talk about its disadvantages, including the most commonly mentioned downside: eventual consistency, and how we can deal with it.
Developers that want to know how sentiment analysis works, data analysts that want to squeeze more information from chat logs.