Original link: https://teddy-chen-tw.blogspot.com/2022/06/1event-sourcing.html
June 28 06:30~09:28
▲The system state using Event Sourcing is calculated by replaying (reapplying) events
foreword
In the second half of this year, Teddy is going to start a new course – [Introduction to Event Tracing and Command Query Responsibility Separation Architecture] . Before starting the course, organize the content of the teaching materials into articles. This series of articles is divided into Part 1 and Part 2, first to introduce Event Sourcing and then to introduce CQRS.
***
Two common ways to store states
Event Sourcing, translated as “event source” or “event source”, is a way of storing state. Before Event Sourcing became popular, the way most developers stored system state was called State Sourcing or Domain Sourcing . As shown in Figure 1, State Sourcing uses the current state of the system to be stored in the database. The key point of this storage state is that only the current state is stored in the database, and the state of the system is obtained directly from the database. As for the database used, it can be a relational database or a NoSQL database.
In the State Sourcing system, the state change will directly overwrite the existing state of the object. For example, if Teddy’s email in Figure 1 is changed to [email protected] , the data with id=001 in the database will have an The value is changed to [email protected] and the old value is overwritten.
▲Figure 1: Save the system state with State Sourcing
***
As shown in Figure 2, what Event Sourcing stores in the database is not the current state of the system, but all events that have caused the system state to change . The current state of the system is calculated by replaying these events from start to finish (called replay events) . The database that stores events is generally called the Event Store , which can be a relational database, such as message-db (https://github.com/message-db/message-db ), a NoSQL database, or a dedicated database for Event Special purpose databases designed by Sourcing, such as EventStoreDB ( https://eventstore.com ).
In the Event Sourcing system, basically the append only method is used to store events. Events can only be written to the Event Store and cannot be deleted or modified. For example, if Teddy’s email in Figure 2 is changed to [email protected] , a new event will be written to the event stream representing Teddy’s account in the database: EmailChanged { id=001, [email protected] } .
▲Figure 2: Save system state with Event Sourcing
***
audit
Event Sourcing is not a new technology. For example, the bank’s deposit account stores the deposit amount of customers by using Event Sourcing. The transaction log (transaction log) of one transaction and one transaction on the passbook is the event stored in the system. .
Since all state changes made to the system are stored in the form of events, auditing can be achieved. Taking bank deposits as an example, if the bank uses State Sourcing to store your deposit balance, if you think you have a balance of 1 million in the bank, but you only have 100 yuan left in the bank’s information record, what should you do? Whose record shall prevail? For the purpose of auditing, the bank must store each transaction record, even if it is an erroneous transaction record, it cannot be deleted directly , but is offset with another record. For example, the bank account system error, accidentally transferred 50,000 to your account. The bank cannot directly deduct 50,000 yuan from your account and then delete the transaction record, but must add a negative 50,000 yuan transaction record to offset the original wrong transaction.
***
state synchronization
Since Event Sourcing is not a new technology and has been used in certain fields for a long time, why has the term become more and more popular in recent years? It is popular for the same reasons that DDD (Domain Driven Design) is popular, mainly due to the boom in microservice architecture.
In DDD, Aggregate state changes will generate Domain Events , through which Domain Events can achieve state final consistency between different Aggregates. This feature can be applied to decentralized or microservice architectures for state synchronization.
As shown in Figure 3, if the Aggregate of DDD adopts State Sourcing, when storing the state of the object, in addition to the current state of the original object, it is also necessary to store domain events. These two actions must be in the same transaction (transaction) together Completed, the system state will not be wrong . The Transactional outbox design pattern is used to solve this problem in the microservice architecture.
▲Figure 3: State Sourcing saves system state and domain events must be in the same transaction
As shown in Figure 4, using Event Sourcing to store domain events is equivalent to storing the system state, thus avoiding the problem of Figure 3.
▲Figure 4: Event Sourcing saves domain events and saves system state at the same time
One thing to note here, whether Transactional outbox or Event Sourcing is used, in this case the database also acts as a simple Message Bus or Message Broker. That is, the client must be able to read the domain events in the database, and then forward the domain events to other “downstream” Event Handlers or microservices, as shown in Figure 5.
▲Figure 5: Event Store is also Event Bus/Event Broker
***
preference write
Event Sourcing also has the benefit of being fast, easy, and convenient to write. Using Event Sourcing in the context of DDD, each Aggregate instance will have a dedicated event stream in the Event Store to store its domain events. This event stream is usually named in the format of Aggregate Type-Aggregate ID, such as a Account Aggregate instance, its id is equal to 3104ca15-df4a-4878-9342-b6d6d650b4cc, then an event stream of Account-3104ca15-df4a-4878-9342-b6d6d650b4cc will be added to the Event Store to store the event stream of the Account instance Domain events, as shown in Figure 6.
▲Figure 6: Stream Browser screen of EventStoreDB
Compared with using a relational database, the object structure needs to be converted into a relational table (Object Relational Mapping; ORM), Event Sourcing only needs to store domain events, eliminating the tedious setting of ORM . In addition, since data is written to only one Aggregate at a time, there is no need to lock multiple tables when writing with an associative database, so “theoretically” Event Sourcing’s writing performance will be higher.
***
next episode preview
The basic concept of Event Sourcing is introduced here first. In the next episode, we will start writing programs. Taking ezKanban’s Tag Aggregate as an example, we will explain the steps of writing Event Sourced Aggregate and its corresponding Repository.
***
Youzo’s inner monologue: Finally, work started again.
This article is reprinted from: https://teddy-chen-tw.blogspot.com/2022/06/1event-sourcing.html
This site is for inclusion only, and the copyright belongs to the original author.