The ideas of event sourcing are not new, systems were typically built this ways in mainframes before SQL databases came along and databases works with event sourcing internally, Greg Young explained in a recent presentation.
Working with algorithmic trading Greg, lead architect for Event Store and creator of the term CQRS, realised they needed a deterministic system with an audit log which was proven to be correct, common in many regulated industries. From this he came up with an idea:
State transitions are an important part of our problem space and should be modelled within our domain
Modelling this way using events Greg has found that a lot of problems in a domain will go away and notes that within industries like finance, banking or insurance no one is using the concepts of current state. A reason for working so is a need to keep everything that happens; events are never updated or deleted, they are immutable. When an error occur a reversal, cancelling the original event, then applying a new correct event is made. He also emphasizes that the same strategy is possible for any form of current state; make it transient and derived from all events.
Two advantages with event sourcing from a developer’s perspective Greg mentions are:
- Since events are immutable it’s a model that’s very easy scale up, the events can be cached, copied and distributed without any problems.
- Smoke testing is a series of test simulating real usage of a system trying to ensure the system will work in production. Saving all commands it’s possible to rerun all commands ever processed comparing the results with earlier runs with respect to expected changes, which will give a very high degree of confidence the system works as expected.
Overall Greg finds event sourcing a great transactional model for many businesses, being append only and immutable. A problem though is queries like finding all users with a specific name which can be awkward, comparing it with always doing a full table scan in a SQL database. This is where CQRS becomes interesting, separating writing from reading and enabling queries using a separate optimized read model for that kind of queries. It’s also possible to have multiple read models for different kind of queries, e.g. a document database and an OLAP cube.
Greg concludes with:
A single model cannot be appropriate for reporting, searching and transactional behaviours…