• Changing a database is hard when storing state

    

  If you have an application where you store the state it is hard to make changes to this since then you know you have to go over all the code in all the layers and change the structure of that code, and also write some migration script. I you are using event sourcing you just change the event and you are done, as long as you don't change the name of an event or a property of the event, then you have to do some migration of the events. I think it is less common that an event might change than a database changes, since event are smaller and more concise so they are harder to model wrong ones you talked to the business.

    

  Changing the view database in a event sources system is easy. You just drop the database, update the logic and re-applies all the event once again.

• • A process manager or a UI issues a command to reserve seats for two attendees to the conference with an ID of 157. The command is handled by the command handler for the SeatsAvailability aggregate type.
   
  • If necessary, the object-relational mapping (ORM) layer populates an aggregate instance with data. The ORM layer retrieves the data by issuing a query against the table (or tables) in the data store. This data includes the existing number of reservations for the conference.
   
  • The command handler invokes the business method on the aggregate instance to make the reservations.
   
  • The SeatsAvailability aggregate performs its domain logic. In this example, this includes calculating the new number of reservations for the conference.
   
  • The ORM persists the information in the aggregate instance to the data store. The ORM layer constructs the necessary update (or updates) that must be executed.
• • A process manager or a UI issues a command to reserve seats for two attendees to a conference with an ID of 157. The command is handled by the command handler for the SeatsAvailability aggregate type.
   
  • An aggregate instance is populated by querying for all of the events that belong to SeatsAvailability aggregate 157.
   
  • The command handler invokes the business method on the aggregate instance to make the reservations.
   
  • The SeatsAvailability aggregate performs its domain logic. In this example, this includes calculating the new number of reservations for the conference. The aggregate creates an event to record the effects of the command.
   
  • The system appends the event that records making two new reservations to the list of events associated with the aggregate in the event store.
• This second approach is simpler because it dispenses with the ORM layer, and replaces a complex relational schema in the data store with a much simpler one. The data store only needs to support querying for events by aggregate ID and appending new events. You will still need to consider performance and scalability optimizations for reading from and writing to the store, but the impact of these optimizations on reliability and consistency should be much easier to understand.

• You must also ensure that you have a mechanism that enables an aggregate to rebuild its state by querying for its list of historical events.

   

  What you have also gained with the second approach is a complete history, or audit trail, of the bookings and cancellations for a conference. Therefore, the event stream becomes your only source of truth. There's no need to persist aggregates in any other form or shape since you can easily replay the events and restore the state of the system to any point in time.

   

  In some domains, such as accounting, event sourcing is the natural, well-established approach: accounting systems store individual transactions from which it is always possible to reconstruct the current state of the system. Event sourcing can bring similar benefits to other domains.

• Why should I use event sourcing?

   

  So far, the only justification we have offered for the use of event sourcing is the fact that it stores a complete history of the events associated with the aggregates in your domain. This is a vital feature in some domains, such as accounting, where you need a complete audit trail of the financial transactions, and where events must be immutable. Once a transaction has happened, you cannot delete or change it, although you can create a new corrective or reversing transaction if necessary.

     

    

  The primary benefit of using event sourcing is a built-in audit mechanism that ensures consistency of transactional data and audit data because these are the same data. Representation via events allows you to reconstruct the state of any object at any moment in time.
  —Paweł Wilkosz (Customer Advisory Council)

• The following list describes some of the additional benefits that you can derive from using event sourcing. The significance of the individual benefits will vary depending on the domain you are working in.

   
   
  •   Performance. Because events are immutable, you can use an append-only operation when you save them. Events are also simple, standalone objects. Both these factors can lead to better performance and scalability for the system than approaches that use complex relational storage models.
   
  •   Simplification. Events are simple objects that describe what has happened in the system. By simply saving events, you are avoiding the complications associated with saving complex domain objects to a relational store; namely, the object-relational impedance mismatch.

4 more annotations...