CQRS Without Ceremony
CQRS separates operations that change the system from operations that read from it. In Code Genie, that means commands and queries are modelled as different kinds of intent.
The Basic Split
A command changes something. A query asks for information. Keeping that difference visible prevents screens, APIs, and generated code from mixing decision logic with display logic.
- Command: Approve Loan Application.
- Event: Loan Application Approved.
- Query: Show Applications Awaiting Approval.
- Read Model: Underwriter Work Queue.
Why It Helps
Business systems often read data much more often than they change it. They also need different shapes for reading and writing. A command needs the fields required to make a decision. A read model needs the information needed by a person or integration at that moment.
For generation, CQRS gives Code Genie a cleaner map: command handlers and aggregate decisions on one side, query APIs and read models on the other.
Not Every System Needs Full CQRS
Some generated systems can use a simple shared data store and still benefit from command/query clarity. Others need separate read models, projections, queues, or event-sourced writes. Code Genie can hide much of that implementation detail, but the canvas should still show which operations change state and which operations read state.
Good CQRS Candidates
- Task-based user interfaces where users make business decisions.
- High-read systems such as customer portals, catalogues, dashboards, and operational work queues.
- Collaborative systems where many people may act on the same business object.
- Systems where read screens need denormalized, role-specific views.
- Event-sourced systems where events feed projections.
Modelling Rule Of Thumb
If a block changes the business state, model it as a command that may produce events. If a block only asks for information, model it as a query against a read model. If it both reads and writes, split it so Code Genie can generate a clearer design.