Using Just Enough CQRS: A Group of Stores

Discuss how to implement the read models, and refactoring for event handlers.

The Store Management module has a number of existing queries in the application. Some we might be able to serve from the event store, such as GetProduct() and GetStore(), but the others, such as GetParticipatingStores() or GetCatalog(), would require scanning the entire table to rebuild every stream, and then we would filter a percentage out.

When we created the events table in the previous section, we left the existing tables alone. This was a tiny bit of cheating on our end. Although we knew the tables would be used again for our read models, it might not always be practical to reuse old tables. In most cases, the tables that support our read models should be specifically designed to fulfill requests as efficiently as possible. The tables that are left over after a refactoring might not be suitable for that task.

We could also use entirely new tables, use a new database, and even do more beyond using different read models. Right now, our only need is to get the queries working again and the discarded stores and products tables will do the job and already exist. We can also repurpose some discarded code to create our read models quicker.

A group of stores is called a mall

A new interface, MallRepository, needs to be created to house all the queries that StoreRepository will be unable to handle. To create the read model, we will need to project the domain events into it with an event handler.

This is the MallRepository interface that will require a PostgreSQL implementation:

Get hands-on with 1400+ tech skills courses.