What do Domain Events have in common with Event Sourcing ? Definitely the word “event” in their name. But also, when I talk about architects and developers in projects, conferences, or training, I often hear that domain events are well suited to event sourcing and that event sourcing is an idea of the domain’s source. events. In this article I would like to summarize why I personally disagree with this view.
First I will argue why I do not share this view, I want to ensure a full understanding of domain events and event sourcing.
Domain Events
In domain-driven design, domain events are described as a number of things that occur in the domain and are important to domain experts. Typically events occur regardless of the domain level deployed in the software system. They are also independent of technologies. Accordingly, domain events are semantically high-valued, they are expressed in languages spoken by domain experts. Eg:
- A user has been registered.
- An invoice has been received.
- Payment term has expired.
Domain events are related both within a bounded context and run through bounded contenxt for deploying processes within the domain.
Event Sourcing
Martin Fowler describes the main characteristics of event sourcing in his article as follows:
Event Sourcing ensures that all changes to application state are stored as a sequence of events.
Instead of saving the current state inside the application directly, using the fields in the database table, we will save a list of events, after running these events in turn, we will have Get the current state of the object. It will be overwritten by later changes.
Event sourcing is a general concept, but is often discussed in the context of domain-driven design in connection with aggregates. So I use aggregates sustainability as an example for using event sourcing.
The sequence below shows the steps involved when using event sourcing for permanently storing the state of an aggregate:
An action related to the business will be called on an existing aggregate. Two previous events have been maintained for this aggregate
Before the request is processed, an empty instance of the aggregate is created and the previously stored events run on the aggregate. Aggregate only reads the status of the corresponding events and no business is executed. When completed, the aggregate contains its current state in memory.
The request is accepted by the aggregate, confirming the current state and processing, etc. The corresponding domain logic is executed. At that time, none of the internal states of the aggregate were changed, this was only done after the event handling was generated during the invocation process.
As a result of the request processing, the aggregate produces an event (or several events), including the state required for rebuilding the state in the aggregate. The event is thus maintained, which can be used for future calls.
The main advantages are listed below when using event sourcing:
- The stored event describes not only the current state of the object, but also the history of its creation.
- It can be rebuilt at any time for any past state by re-running events with a certain timeline.
- It is understandable to use event sourcing to handle the error processing of previous events or delayed events.
Deploying event sourcing also requires a complex concept and technology. Events are not allowed to change once they exist, while domain logic often grows over time. So the code must be able to handle even very old events. Snapshots are needed to rebuild state based on a large amount of history of events in some way.
Events in Event Sourcing are different from Domain Events
So why do I think that these two concepts don’t really fit together so well?
Consider the example below: In a bicycle sharing domain, a user wants to register to rent a bike. Of course, one has to pay for it, which is done through the payment approach using an electronic wallet.
The relevant parts of the context map for this domain look like this:
Processing registration works as follows:
- The user enters his phone number via the mobile application.
- User receives a code from SMS to confirm the phone number.
- User enter the verification code.
- Users enter additional details such as name, address, .. and complete the registration.
This process is implemented in the aggregate UserRegistration in bounded context Registration . The user interacts with the instance of the UserRegistration aggregate several times during the registration process. The status of UserRegistration is built step by step until the registration is completed. Once completed, users can pay for e-wallet and bicycle rental.
Now, if event sourcing is used to manage the state of the UserRegistration aggregate, the following events (containing the corresponding related state) are created and maintained over time:
MobileNumberProvided(MobileNumber)VerificationCodeGenerated(VerificationCode)MobileNumberValidated(no status added)UserDetailsProvided(FullName,Addresss, …)
These events are sufficient to rebuild the current state of the UserRegistration aggregate at any given time. Adding events is not necessary, especially there are no events showing that the registration has been completed. This fact is known for UserRegistration internal UserRegistration domain logic aggregate as soon as the UserDetailsProvided event is processed. Accordingly, an instance of a UserRegistration can reply at any time whether the registration has been completed or not.
In addition, each event contains only the state that is needed to be able to rebuild the state of the aggregate during rerun. Usually these are only the states affected by the event invocation. From the event sourcing approach, it makes no sense to store additional state on the event without being affected by invocation. Thus, if the UserRegistration event has been maintained, it will not contain any additional status.
The Aggregate UserRegistration can also be published to other sections within or outside the bounded context and thus may trigger additional domain logic or update a number of other states. In our example, there are 2 bounded context Accounting (for creating a digital wallet) and Rental (for creating registered users).
Discuss
In the article, the author explained the differences between Domain events and Event sourcing, the requirements of event sourcing. Also clarify when to use them. Hope to bring you some useful points.
The article has been translated from the source:
https://www.innoq.com/en/blog/domain-events-versus-event-sourcing/