DEV Community: Khashayar Nourian

CQRS with a separate read store: useful projections, new guarantees

Khashayar Nourian — Mon, 07 Sep 2026 00:00:00 +0000

A separate read store is not the next mandatory CQRS step. It is useful when a screen, report, or read workload needs a shape that the transactional write model should not own.

For an order-tracking screen, a projection can keep one denormalized row with an order number, customer name, status, last-updated time, and total. That can remove repeated joins and let read traffic scale separately from command handling.

The trade-off is visible behavior. A command can commit before the projection updates, so the next read can be stale. Treat the write side as authoritative, make projections rebuildable, and state what the user should expect after a successful command. If a shared database and direct projection already work, keep them.

Minimal CQRS: separate code paths, keep one application and one database

Khashayar Nourian — Thu, 03 Sep 2026 00:00:00 +0000

CQRS does not have to begin with a second database, a queue, or a separate service.

A useful first step is much smaller: keep one application and one database, but give commands and queries separate code paths. A command such as PlaceOrder loads the state it needs, checks business rules, and commits a change. A query such as GetOrderSummary can project exactly the fields a screen needs without rebuilding a domain aggregate.

The database is shared. The responsibilities are not.

This keeps transactions, immediate reads after a successful command, and a simple deployment model. It does not create independent read scaling or reporting projections for free. Those are later decisions, not a starting requirement.

CQS and commands: make the application understand intent

Khashayar Nourian — Wed, 26 Aug 2026 00:00:00 +0000

SetStatus(itemId, Deactivated) tells an application what a field should contain. DeactivateInventoryItem(itemId, reason) tells it what the user wants to do.

That difference matters when the action has rules. A deactivation may require a reason, permission, a valid state transition, and a transaction that saves the result. With a behavior-focused command, those concerns have one natural home instead of being inferred from changed fields or scattered between the UI and a generic update handler.

The UI can still help by explaining obvious failures early. It cannot be the final authority because another client, a retry, or a concurrent request can reach the same operation.

A command is also not an event. A command asks for work and may be rejected. An event describes something that already happened after the command succeeded.

When CRUD stops describing the work

Khashayar Nourian — Mon, 24 Aug 2026 00:00:00 +0000

CRUD is not the enemy. It is often the smallest correct design for a profile, a team setting, or a simple lookup table.

The trouble starts when a changed object hides a business action. An API that receives an updated inventory DTO can see that Status became Deactivated, but it still has to infer why that happened, whether a reason is required, who is allowed to do it, and what should happen next.

That is where Command-Query Separation helps. A query returns information. A command asks the system to change something. DeactivateInventoryItem(id, reason) says more than a generic update ever can.

This does not require two databases, a message broker, or microservices. It starts with making the request visible where the rules belong.