Some problems can actually be solved elegantly with a blockchain, for example the conclusion of digital contracts. However, the procedure is too complex for most other problems. After all, the blockchain is a distributed system per se, and such systems always involve a certain complexity. Therefore, the decision to build a system based on a blockchain should be well considered.
The basic motivation for using a blockchain-based technology is often the requirement to be able to track changes. Who made which change, when and for what reason?
Even if the hype surrounding the concept of the blockchain suggests something else, the idea of saving changes in a traceable way is not new. Therefore, there are alternatives to using a blockchain, which are preferable depending on the application. One of these alternatives is the so-called event-sourcing.
The idea behind this approach is not to save the current state of the data, but the changes that have led to the current state over time. Ideally, these changes are mapped to semantic domain events. On the way, it is not only possible to trace which changes were made when and by whom, but also why.
Event sourcing without CQRS and DDD
Event-sourcing is often mentioned in combination with CQRS and domain-driven design (DDD). This occasionally gives the impression that event-sourcing must necessarily be used in conjunction with these concepts. However, this is not the case.
In a sense, a blockchain is nothing more than one way of implementing a distributed event-store. The disadvantage of this approach, however, is that the blockchain does not guarantee the integrity of data – changes may be discarded if the majority of the network decides to do so.
This is exactly what event-sourcing avoids: Since a central instance controls the integrity of the data, you can rely on it to a greater extent. Especially as an alternative to CRUD, event-sourcing is an interesting approach that includes support for historical data by default and enables highly interesting analyses.