2. Briefing “We can query an application's state to find out the
current state of the world, and this answers many
questions. However there are times when we don't just
want to see where we are, we also want to know how
we got there.”
Martin Fowler, 2005
3. Usual Design
● Modeling the domain entities and convert into tables, documents to store at
some database
4. Failures
● “Hello, what’s happening?”
○ Code : “I have a dog, a car, an apartment ...”
○ Real life: a list of event that creates a story
● Loss of information
○ You can inform only the current state
○ You don’t have the information of how you got there
○ “How many times the customer take out some product of his cart and after put it back? ”
5. Event Sourcing
● Queue where is stored all the events ;
● Everytime that some state entity (object) changes a new event is add to the
queue;
● Every event that goes to the event store is delivered to all interested
subscribers;
6. Event Sourcing
● Communication between services:
○ Write an event listener that runs whenever that event is fired. This allows
you to add new integrations/functionality, without having to modify
existing domain code.
● Register an user → User created event
E-mail Service
SMS Service
7. Event Sourcing
● Good Points:
○ Provides an audit log of every changes in a entity
○ Create the possibility of temporal queries (time machine :D)
○ “How many times the customer take out some product of his cart and after put it back? ”. To
figure out the answer you need to analyse the store of events
● Must take care:
○ Eventual consistency
○ There a time between the event occur, the other system receive and process the event