Read Model

The purpose of separating it is that write and read have genuinely different requirements. A write model is shaped by invariants — normalised, constrained, protecting correctness. A read model is shaped by the screen — denormalised, pre-joined, pre-aggregated, so a page renders from one lookup.

A read model need not be a database table. It is frequently a search index, a cache, a materialised view, or a document store, chosen per query.

Three properties that come with it and must be designed rather than discovered:

It is stale. How stale is a product decision, and it should be stated, measured and alerted on — the failure mode is a projection that silently stops updating and keeps serving.

It is disposable and rebuildable. This is the underrated benefit: a read model can be dropped and rebuilt from the source, which makes a bug in projection logic a re-run rather than a data migration. That property is worth preserving deliberately.

There can be many. Once the mechanism exists, a new read model for a new screen costs a projection rather than a schema change to a shared table — which is what makes CQRS pay off over time rather than at the start.