This is an example of how to interact with a shopping cart by emitting actions or events.
A processor
object dispatches incoming events to susbcribers, who are in charge of mutating data (an order
in this case).
Run a simple user session that interacts with the cart with
ruby user_session.rb
This will update the order and print it to the screen.
It will also log all events to ./events.log
.
You can re-play the events log against a new blank order with
ruby buid_from_log.rb
This should re-play the event history and recreate the exact same state that you got to by running the user session.
Modelling all actions in the system as a flat list of actions or events could have some benefits:
- you can recreate the state of the data just by re-playing the event log, in order.
- you can re-play parts of the history to help you debug user or other actions.
- you can re-play events against new code, for example to generate analytics or store data in different places
- backups and replication are easy, just append events to a new log somewhere
- event subscribers can be in your own code, or they can subscribe over the network. You can build a plugin or addon system. A new addon just needs to subscribe to the events it's interested in.
These are the ideas behind the Event Sourcing pattern, Apache Kafka and others.