August 16 10:03~11:33
▲Figure 1: Clean Architecture four-tier architecture
foreword
Last weekend, I finished the first group of [ Event Tracing and Command Query Responsibility Separation Architecture Implementation Class ], and a veteran student who had known each other for nearly ten years told Teddy: “This is the most difficult course I have taken in all Teddy software courses. .I can directly select a certain part to apply in my work when I go back to the previous class. I can’t think of where this Event Sourcing plus CQRS can be used.”
Is Event Sourcing really more difficult than State Sourcing (OR-Mapping)? This time, I will discuss this issue in two episodes. In this episode, we will first compare the similarities and differences between the two from the writing (Command/Write Model) , and then discuss the reading in the next episode.
***
just different
Teddy felt that the main reason why this old student found it difficult was that in the course, Teddy concentrated all the key points of Event Sourcing, CQRS, DDD, and Clean Architecture that he had learned in recent years in two days, so the information density relatively high. As for Event Sourcing itself, Teddy believes that it is not more difficult than State Sourcing. The difficulty is that the time when you want to apply Event Sourcing is usually in a distributed system or a microservice architecture. It is this “distributed environment” that makes you mistaken for Event Sourcing. Sourcing is harder, not really harder by itself .
Compared with State Sourcing, Event Sourcing is just a different approach, not more difficult; they are just a way to store the state of the system.
***
Looking at Event Sourcing from Clean Architecture
Please refer to the Clean Architecture diagram in Figure 1:
Entity Layer : The Entity Layer first reflects the important concepts and associations of the problem domain. In theory, the objects in this layer do not matter how the objects are stored. But in terms of program implementation, Event Sourcing does have an impact on the implementation of the Entity Layer, but it only affects the Aggregate Root. The programming style should be changed to the event sourced coding style as shown in Figure 2: any public that changes the state method, both call the apply method and pass it one (or more) domain events representing state changes. The program logic is then implemented in the event handler (the when method in Figure 2). This style of programming can also be applied to state sourcing, so it does not mean that event sourcing must be used in this way.
▲Figure 2: Event Sourced Aggregate Root writing style
***
Use Case Layer : Please refer to Figure 3. The Use Case accesses Aggregate through the injected Repository. The Use Case does not know whether the injected Repository is a Stage Sourcing Repository or an Event Sourcing Repository. In other words, whether to use Event Sourcing does not affect the Use Case.
▲Figure 3: Use Case example
***
Interface Adapter Layer : Please refer to Figure 4. The right side of the Interface Adapter Layer is the implementation of State Sourced Repository, and the left side is the implementation of Event Sourcing Repository. From the perspective of write (Write Model) , if it is State Sourced Repository using OR-Mapping, because it needs to write a bunch of ORM settings or write SQL to the database, the implementation method is actually more than Event Sourced Repository. It is complicated, and there is no problem that the storage method of Event Sourcing is more difficult than State Sourcing.
▲Figure 4: Interface Adapter Layer and DB & Driver Layer
***
DB & Driver : Please refer to Figure 4. The right side of the DB & Driver Layer is the State Sourced Database, and the left side is the Event Sourced Database. If a relational database is used on the left side, while writing Aggregate to the database table, it is necessary to also write the domain events to the Outbox table of the database in the same transaction. As for the Event Store Database on the right, since it only needs to write domain events, it is not necessary to apply the Transactional Outbox design pattern when writing like a relational database, so it is relatively simple.
***
in conclusion
After the above analysis, from the perspective of read-write separation, Event Sourcing is actually simpler than State Sourcing on the write side. But as Teddy often said “energy is immortal”, writing is relatively simple, and reading is usually more difficult. The next episode starts with reading the model to compare Event Sourcing and State Sourcing.
***
Business Services
Finally, make an advertisement. [ Collar ] is recruiting in October .
***
Youzo’s inner monologue: Event Sourcing is a technology that hurts the first time and feels cool the second time XDD.
This article is reprinted from https://teddy-chen-tw.blogspot.com/2022/08/event-sourcing-cqrs.html
This site is for inclusion only, and the copyright belongs to the original author.