August 17 21:54~22:49
▲Figure 1: Repository interface
foreword
In < I may not use you, Event Sourcing + CQRS? ! (Top) > Teddy mentioned that Event Sourcing is not more complicated than State Sourcing when writing the model (Write Model/Command Side), or even simpler.
But things are usually one or the other. Writing is relatively simple, but reading is more difficult. Today, we will discuss the situation of Event Sourcing in the reading model.
***
Data query across Aggregate
After applying DDD (Domain Driven Design), Aggregate Root is responsible for emitting domain events and then storing its state through Repository. When using Event Sourcing, an aggregate instance will have an event stream in the event store to store all its domain events. Each Repository (Repository design pattern in DDD) is responsible for storing and loading “single Aggregate”, and its interface is shown in Figure 1.
Figure 2 shows the domain model of the core domain of the ezKanban system, which includes four Aggregates: Board, Workflow, Card, and Tag. Now the question comes: “How to check how many workflows are in a Board? How many cards? How many tags?”
If the DDD Repository design pattern is positioned as “an interface dedicated to accessing a single Aggregate in the Write Model”, and the Write Model does not need to maintain “the association for querying”, then in the Write Model, the Board does not know it How many Workflows and Tags are on it, and Workflow does not know how many Cards each Lane has on it.
▲Figure 2: ezKanban domain model
So Event Sourcing makes writing very simple, but querying is more difficult, especially for queries across Aggregates. Regardless of efficiency issues, developers can still use the Projection function built into EventStoreDB to read out domain events and “spell out” the read model in memory, but the execution speed is obviously slower. Therefore, in the case of applying Event Sourcing, a View Model is usually specially designed for a special query screen or report to speed up the reading speed.
In the case of State Sourcing, if a relational database is used, the query can directly download the SQL to find the required data. But this does not mean that State Sourcing will not have the problem of too slow query efficiency. Similarly, for individual query screens, State Sourcing often builds a Read Model to speed up the query. In other words, the additional establishment of Read Model is not a patent of Event Sourcing. In the State Sourcing system, SQL, Join, and Create View are all methods of generating Read Model.
***
Event Sourcing in the end
Traditionally, CQRS is applied in Event Sourcing systems, and the choice of Read Model database can be the same or different from Write Model (seems like nonsense). For example, if Write Model uses EventStoreDB, Read Model may use relational database or NoSQL. But there is another school of practice: “Since Event Sourcing is required, Event Sourcing is required to the end. Write Model and Read Model are both Event Sourcing.” What does this mean? Please refer to “Event Sourcing (11): Writing JavaScript to Generate Custom Projections in EventStoreDB” , Teddy introduced that EventStoreDB can automatically generate projections for queries by writing JavaScript programs, and then use these projections to generate Read Models. In this case, Write Database and Read Database can be combined into one.
***
in conclusion
Seeing this, the villagers may think: “Teddy, you still didn’t say that Event Sourcing + CQRS is more difficult than State Sourcing?” Where is it different:
- At first glance, Event Sourcing is easier to write and harder to read, and State Sourcing is the opposite.
- In fact, it is “energy is immortal”, and each has its own difficulties. Event Sourcing does not need to design a database schema, which feels great. But the problem of designing the database schema has not disappeared, it has just turned into the design domain event schema.
Teddy’s purpose in writing these two articles is not to advocate the use of Event Sourcing, but to remind everyone that it is a way to store state, and it is no harder than State Sourcing. If you find a suitable use case for Event Sourcing, use it to simplify the system design. If your application scenario does not need to record all state changes, and you are not familiar with Event Sourcing, then just use the State Sourcing that you are used to, and don’t have to catch up.
However, there is no harm in knowing more about a state storage method. It is difficult to guarantee that a suitable application scenario will appear one day. At this time, it is not known that Event Sourcing may design an overly complex system.
***
Youzo’s inner monologue: Learning new technologies is for the ability to see forces in the future.
This article is reprinted from https://teddy-chen-tw.blogspot.com/2022/08/event-sourcing-cqrs_17.html
This site is for inclusion only, and the copyright belongs to the original author.