Combining CQRS and event sourcing

- [Instructor] Let's see what the combination of CQRS and Event Sourcing would look like. The terms CQRS and event sourcing are often used interchangeably, but they are fundamentally different. And even though one can be implemented without the other, the combination can be very powerful. We'll start with an event sourced application. Our entities are built by replaying events on a new object. That's how we restore the state of an object. When we want to alter the state, we add a new event and handle that event. When we persist events, we can trigger event handlers to perform actions on other objects or systems. To add CQRS to the mix, we want to separate our read model from our write model. In our event sourced application, the whole system of events and handlers is our write model. To add a read model, all we need to do is make event handlers that populate the read model. Then we can add the necessary code to query this read model. Combining CQRS and event sourcing gives you the best of both worlds. The advantages of event sourcing, were having another trail of which actions were executed on an object, and being able to use the language that the end user uses. Adding CQRS means we don't need to replay the events to display data to a user, and it scales better. But combining these two patterns also means you have the downsides of both. There are more components that interact with each other, making it slightly more difficult to learn. Because of the CQRS pattern, your read model can become out of sync with your write model. Also, when you want to change the structure of an event, for example, by renaming a property, your code needs a way of handling this correctly because the events stored in the database will still be using the old property name. So let's see this in action. In the exercise files, you'll find the fictional travel agency web application we've been using throughout this course. For the end user, it still behaves the same, but let's look under the hood. I've added a breakpoint in the booking overview item generator. It's an event handler in the event sourcing architecture, and it's responsible for creating a read model in our CQRS architecture. We'll now start debugging the application. Like in previous videos, you'll get a dashboard where you can navigate through to the website. Let's navigate to the list of tours, select one, and create a new booking. Now our event sourcing system has done the necessary work to store the events of the new booking, and because of that, the event handlers kick in, they can call external APIs, send an email, and in this case, update our read model. So if I just continue and we'll check our database, we can see that a record has been added to the event table, and also in the booking overview item table, a record has been added. This record can then be used to easily populate an overview of bookings in the user interface without the need to join to other tables. So when should you use event sourcing or CQRS and when should you combine the two? First, don't use it for simple domains that have no need for the advantages of these patterns. If you decide event sourcing could be useful for you, start with event sourcing without CQRS and add CQRS later. It's harder to modify your architecture for event sourcing than it is to add CQRS.