Event Sourcing as replacement for CRUD

Most developers are familiar with CRUD (create-read-update-delete) model of data storage in business applications. It is a simple model that has served us well so far. But the problem with CRUD is that it allows users (or developers) to modify history (change past). That might be okay for some applications (a discussion board, say), but not for all, such as financial accounting. In this article is a very gentle introduction to an alternative model, Event Sourcing. There are more detailed introductions elsewhere, but they may not be as gentle (Subjective, I know).

For example, one of SpinSpire's financial clients has an application that currently uses CRUD model for accounting financial transactions. The problem is that the application allows users to go back and adjust (modify) financial transactions that have already happened, reconciled and reported to the relevant authorities (regulators). So, in effect, you're changing the past. Now, you may say, that "Hey, we need to be able to update the data as new and more accurate information becomes available!". True. But the right way would be if the database had two entries - one entered originally, and another one entered later that adds the adjustment amount. And both the entries have separate timestamps on them. So if you queried the database with an "as-of" time, you'll get one answer before the second entry, and a different answer after it.

The above is what Event Sourcing (ES) accomplishes. In CRUD, the database simply stores that transaction amounts as they stand now. But in ES, the database is a journal of transaction entries with a timestamp that can be sequenced up to any "as-of" time to reflect the situation as it was at that time. Implementing this (ES) is not easy. But for mission-critical systems where historical accuracy is paramount, there's much of an alternative.

In a later update, I'll try to go into the details of ES and how to implement it. In the meanwhile, checkout some of the resources below ...