Read Model Block
A read model is information shaped for a user, policy, query, report, dashboard, or external consumer.
When To Use It
Use a Read Model block when the system needs to present information without changing business state. Read models are often optimized for a specific task: an approval queue, customer account summary, shipment tracking view, risk dashboard, or billing history.
Required Data
- Name: task-focused information name, such as Claims Awaiting Review.
- Consumers: user interfaces, queries, policies, reports, or integrations that use it.
- Fields: data shown or returned.
- Source events or data sources: what keeps the read model up to date.
- Freshness expectation: immediate, near-real-time, periodic, or on demand.
Recommended Data
- Filters and sorting: how users find the right information.
- Security: who can see which fields.
- Pagination or export needs: useful for generated APIs and screens.
- Projection rules: how domain events change the read model.
- Staleness message: user-facing wording if the model can lag behind writes.
Connections
- Updated by Domain Events or integration data.
- Returned by Queries.
- Displayed in User Interfaces.
- May provide decision data for Policies.
Examples
- Order Status Summary: order number, customer, current status, payment state, shipment state, next action.
- Underwriter Work Queue: application id, applicant, risk score, requested amount, SLA age, assigned underwriter.
- Subscription Health Dashboard: account, plan, seats used, payment status, renewal date, support risk.
Generation Notes
Code Genie uses read models to generate query endpoints, projection handlers, data transfer objects, dashboards, list pages, detail views, and policy decision inputs. Read models should be shaped around usage, not around aggregate internals.