In Event Storming, a popular workshop-based method for domain-driven design (DDD), the Read Model refers to a pattern for querying data efficiently in complex systems. It plays a key role in Command Query Responsibility Segregation (CQRS), which is often used in systems that emerge from Event Storming sessions. Let's break down its role in the context of Event Storming:

Event Storming Overview  

Event Storming is a collaborative modeling method where participants (developers, domain experts, etc.) brainstorm and map out domain events (something that happened in the system). This allows everyone to understand the business domain and its behavior through these events.

Core Event Storming Concepts 

 

- Domain Events: These represent key events that occurred in the domain, typically described in the past tense (e.g., "Order Placed" or "Payment Received").  

- Aggregates: These are clusters of domain objects that maintain consistency boundaries. They receive commands and produce events.  

- Commands: Instructions from users or other systems, often triggering a domain event.  

- Projections: Views of domain events that allow for querying and retrieving meaningful information from past events.

The Role of a Read Model  

The Read Model in Event Storming, when CQRS is applied, handles queries in an optimized way by focusing purely on retrieving data. It is separated from the Write Model, which is responsible for handling commands and applying domain logic.

1. The Read Model stores the projections of the system's state derived from domain events. These projections are tailored for fast and efficient querying rather than mirroring the domain’s actual structure.

2. Querying the Read Model: 

 

   - When you need to query the system (e.g., get the order history of a customer), the query is directed to the Read Model, which contains data that’s been optimized for retrieval, often stored in formats like views, denormalized tables, or even different databases.  

   - The Read Model can be updated asynchronously by listening to domain events. Every time a domain event is triggered (e.g., "Order Created", "Order Shipped"), it updates the projections in the Read Model to keep them in sync with the actual events.

How It Fits into Event Storming:  

- Events → Read Model: In Event Storming, the events that are discovered during the workshop (like “Payment Processed” or “Order Delivered”) directly influence the data captured by the Read Model.  

- Projections: The data captured by the Read Model can be thought of as projections of these domain events. They provide the system with an optimized view for querying, without needing to handle the complexities of the write logic.  

- CQRS: Often after Event Storming, CQRS emerges as a natural pattern because the model reveals a need for different data handling approaches for commands (writes) and queries (reads). The Read Model is the "query" side of this pattern, which relies on events to build up a representation of the system’s state that is queryable.

Key Characteristics:  

- Denormalization: Read Models are often denormalized, meaning they store data in a way that’s optimized for the specific queries they need to serve, even if that means duplicating data across multiple tables or stores.  

- Asynchronous Updates: The Read Model is updated asynchronously based on domain events, which can lead to eventual consistency (where the Read Model catches up with the latest state over time, but not instantly).  

- Tailored Views: Different Read Models can be created to serve different parts of the system. For example, one Read Model could be optimized for reporting, while another might serve a dashboard for customers.

Example:  

In an e-commerce system, when a customer places an order: 

 

1. A domain event like "Order Placed" is raised.  

2. This event is processed by the Write Model (which handles business rules).

  

3. The Read Model receives a projection of this event (like "OrderHistoryProjection").  

4. Later, when a customer queries their order history, the system queries the Read Model, which quickly provides the relevant data without touching the Write Model.

Summary:  

In Event Storming, the Read Model is part of how a system can be modeled to handle queries efficiently. It is built using projections of domain events and is separate from the logic that handles commands. The separation of reading and writing concerns through concepts like CQRS and projections helps systems scale better and provides a clear understanding of domain behavior.