August 02, 2015
This post is a [WIP] Work In Progress
Last month I attended a talk by Scott Bellware at the Austin Texas Ruby meetup. The topic Scott presented on was on Event Sourcing. I found the topic to be intriguing for working with data within the context of an application we want to update some data, but we don’t want to mutate the data that we currently have and loose the content of the data we currently have. In comparison to a relational design, an event sourcing design has some variations.
- Loose previous info when updating
- Difficult to debug
- Slow performance
- Couples differient entities (tables) to each other
Event Sourcing Design
- Immutable events
- Audit log
- Reconstitute state at any given point
- Avoids normalization which helps avoid coupling
The project that Scott has been working on is the Eventide Product and is a Ruby based software.
The pattern is a result of event-driven architecture and allows for reliably publishing of events whenever state changes. Event Sourcing persists each business entity as a sequence of events, which are replayed to reconstruct the current state. It eliminates the object‑relational impedance mismatch problem and makes it possible to reliably publish events whenever state changes.
Because it persists events rather than domain objects, it mostly avoids the object‑relational impedance mismatch problem. Also, It provides a 100% reliable audit log of the changes made to a business entity. It makes it possible to implement temporal queries that determine the state of an entity at any point in time and event sourcing-based business logic consists of loosely coupled business entities that exchange events which makes it a lot easier to migrate from a monolithic application to a microservices architecture.
One drawback of event sourcing is that the event store is difficult to query since it requires typical queries to reconstruct the state of the business entities. That is likely to be complex and inefficient. As a result, the application must use Command Query Responsibility Segregation (CQRS) to implement queries. This in turn means that applications must handle eventually consistent data.
CQRS & Domain Driven Design
Command Query Responsibility Segregation (CQRS) is split into two parts. A command side which handles create, update and delete requests, and a query side, which handles queries using one or more materialized views of the application’s data.
Written by Mike Hacker, a Native Texan, who lives and works in the Austin/San Antonio, Texas area. You should follow him on Twitter