DEV Community: Khashayar Nourian

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.