Strict CQRS says a command handler should only accept or reject a command, not return domain data - commands are effectively void. In practice, a client submitting `CreateOrder` usually needs the new order's ID right away. What do teams typically do to reconcile that need with the 'commands don't return data' rule, and what does each option cost?

## Where the rule comes from, and what it collides with The strict CQRS rule that command handlers should not return domain data comes from the deeper principle that the write side and the read side are meant to be **separately optimized, separately scaled, and ideally unaware of each other's internal representations**; if a command handler routinely returns rich domain objects, callers start depending on write-side shapes for read purposes, which re-couples the two sides the pattern was meant to decouple. But this rule collides head-on with a **near-universal practical need**: when a client submits `CreateOrder`, it almost always needs the new order's identifier immediately — - to display a confirmation page, - to construct a follow-up API call, or - to store a local reference — and that need doesn't go away just because the architecture says commands shouldn't return data. | Resolution | What it costs | |---|---| | **the client generates the identifier** before the command is sent | architectural rather than statistical: the server has to trust and validate a client-supplied identifier, which can complicate migrations away from UUID-style keys later, and forecloses database-assigned sequential IDs | | **the handler returns just the new ID**, or a pointer such as an HTTP `Location` header | almost zero extra — by far the most common choice in production REST-over-CQRS systems | | **the two-step command-then-query flow** | an extra network round trip, added client-side complexity if the read model lags, and a subtle race | ## The first resolution: the client generates the identifier **The first resolution**, and arguably the cleanest, is to remove the need to return anything at all by having the client generate the identifier before the command is even sent. The client creates a UUID locally, includes it as a field on the `CreateOrder` command, and the server simply uses that ID as the aggregate's identity rather than generating its own. Since the client already knows the ID the moment it constructs the command, there is **nothing for the handler to hand back** — the command genuinely can remain void, and CQRS purity is preserved. This mechanism exists because UUIDs, particularly version 4, have collision probabilities low enough to be treated as effectively zero at realistic scale, so client-side generation is safe in practice; the real cost is architectural, not statistical — the server has to trust and validate a client-supplied identifier rather than controlling ID assignment itself, which can complicate migrations away from UUID-style keys later, and it forecloses database-assigned sequential IDs, which some systems rely on for ordering or index locality. ## The second resolution: a bare identifier back **The second resolution** is to bend the strict rule pragmatically: let the handler return just the new ID, or a pointer such as an HTTP `Location` header, without returning any other field of the order. The argument for treating this as acceptable rather than a violation is that a bare identifier is arguably part of the accept/reject contract — proof that something was created and a handle to reference it — rather than a projection of read-model data; it's categorically different from the handler returning the order's full current state, its computed totals, or anything that would require consulting the read side. This is by far the most common choice in production REST-over-CQRS systems, because it costs almost nothing extra and matches how HTTP already expects a `201 Created` response to include a `Location` header pointing at the new resource. ## The third resolution: command, then query **The third resolution**, the two-step command-then-query flow, treats the rule as inviolable: the handler returns strictly success or failure with no payload, and the client follows up with a separate query, such as 'fetch my most recently created order', to learn the ID. This is the option most true to doctrinaire CQRS, and it becomes not just a style choice but a genuine architectural necessity in systems where the write and read sides are different physical stores that synchronize asynchronously — an event-sourced write store feeding an eventually-consistent read-model projection, for instance — because in that setup the command handler may complete and commit before the read model has even been updated, so there may be nothing correct to return synchronously even if the rule were relaxed. The cost is: - an extra network round trip, - added client-side complexity to handle the query returning nothing yet if the read model lags, and - a subtle race if the client's query criteria, like 'most recent order for this user', could plausibly match more than one order created in quick succession. ## When the read side forces the choice A concrete real-world illustration: many event-sourced systems that project into a separate read database, such as one backed by Elasticsearch or a materialized-view table, cannot return the newly created order's data synchronously from the command handler at all, because the projection that would serve that read hasn't run yet — so these systems are effectively forced toward either client-generated IDs, so the client already has what it needs without asking, or an explicit 'pending' UI state that polls or subscribes for the read model to catch up, rather than assuming a command's completion implies the read side is immediately queryable.