Event-sourcing is about how the state of the system is stored. Normally the state of the system is persisted into the database as a number of related tables. Changes to the state are reflected in the database by modifying, adding, or deleting table rows. The database contains the current state of the system with this approach.

Event-sourcing provides an alternative method. It handles updates of the state very much like functional programming handles effects. Instead of executing a computation, it just describes it so that it is possible to execute it later. Descriptions of computations can be combined, as we saw in the second section of this book. The same way the changes of the state can be combined in an event-sourced approach to produce current state. In essence, event-sourcing is to the state what functional programming is to the computations and effects.

This description of the state change is called event and it usually (but not necessarily!) corresponds to some user action, called command. The system receives commands, validates them, and if the command makes sense in the context of current system state, respective event(s) is created and persisted into the event journal. The event is then applied to the in-memory representation(s) of the state and the required side-effects are executed.

When the event-sourced system is restarted, the events are read from the journal and applied to the initial state one by one, modifying it but not executing side-effects. At the end, after all events are applied, the internal state of the system should be the same as it was before the restart. Hence, events are the source of the state representation of the system in this scenario. The reconstructed state often represents only one aspect of the whole system and is called view.

The event journal is used only for appending events. Because of this, it is usually seen as an append-only storage, and often solutions other than relational databases are used. 

CQRS is another name that goes hand in hand with Event-Sourcing. This is an abbreviation for Command Query Responsibility Segregation, which in turn is just a fancy way to name a principle of Command–Query Separation implemented with Command and Query entities (as opposed to the method calls). The CQS principle states that every method should be either command, which modifies the state, or query, which returns the state, and these responsibilities should not be mixed. With Event-Sourcing, this separation comes naturally from the definition of the Event (which is the Command in the CQS definition) and the concept of internal state as a View that needs to be queried separately.

Event-Sourcing has a lots of advantages over the traditional database-mutating approach:

• Append-only approach to store data scales much better than traditional relational databases.
• Events provide audit, traceability, and in the case of special storages, security for free.
• No need to use an ORM.
• The domain model and event model can evolve at a different pace.
• It is possible to recover the state of the system to any specific moment in the past.
• Events can be combined in different ways, allowing us to construct different representations of state. Combined with the previous advantage, it gives us the ability to analyze past data in ways that weren't known at the time of the event's creation.

Of course, there are some drawbacks as well:

• The state does not exists until it is reconstructed from events. Depending on the format of the journal, it might even impossible to analyze the events without writing special code for this purpose. In any case, it requires some effort to build the state representation from events.
• Explosion of domain model in complex projects. Implementing new use-cases always requires the introduction of new commands and events.
• Changes in the model as the project evolves. Changes in existing use-cases often mean changes in the structure of existing evens, which need to be done in the code because the event journal is append-only.
• The number of events can grow rapidly. In actively-used systems, there may be millions of events produced daily, which can affect the time needed to build the state representation. Snapshotting is used to work around this issue.