A Read Model is a view of data tailored to exactly what a user or system needs to complete a task or make a decision. It’s built for reading, not for updating.
The term appears in two main contexts:
Event Storming – as a conceptual tool for decision-making.
Software Architecture (e.g., CQRS, Event Sourcing) – as a technical pattern for fast, optimized data queries.
The Conceptual View (Event Storming)
In Event Storming, a Read Model is the information an actor must have before issuing a command. It answers:
“What do we need to know to make this decision?”
It’s shown as a green sticky note and can include data from inside or outside the system (e.g., inventory levels, user permissions, a weather forecast). The focus is what information is needed, not how it’s retrieved.
The Technical View (CQRS / Event Sourcing)
In CQRS, a Read Model is a query-optimized projection of data, often pre-calculated from past domain events.
Why use it?
Performance: Deliver instant results without complex joins or calculations.
Simplicity: Provide data in exactly the shape the client needs.
Two approaches:
Pre-calculated: Stored in a database and updated as new events occur.
On-demand: Built by querying raw data or external services in real time.
Example – Scheduling Construction Work
A site manager needs the 7-day weather forecast before scheduling outdoor tasks.
Conceptual Read Model (Event Storming): “7-Day Weather Forecast” green sticky before the Schedule Outdoor Work command.
Technical Read Model (CQRS):
On-demand – fetched from a live weather API.
Pre-calculated – updated in a local table whenever a WeatherForecastUpdated event occurs.
Key Takeaways
Broadly: Any data needed before taking action.
Event Storming: Conceptual decision-making aid (green sticky).
CQRS: Query-optimized data projection.
Always ask: “What information must we see before we act?” — that’s your Read Model.
What is Qlerify?
Qlerify is an online Event Storming tool that makes collaboration smoother, adds structure, and speeds up the design process.
