Cqrs And Handlers (Symfony)
Use when
- Separating writes from reads with distinct command and query buses.
- A service both changes state and returns data for display.
- Adding a use case as a command or a query with its own handler.
Default workflow
- Name the use case: a command changes state, a query returns data.
- Write the message as a readonly class and exactly one handler for it.
- Configure separate command and query buses; give the command bus the
validation and doctrine_transaction middleware.
- Inject the buses behind small interfaces, or the native buses with
#[Target].
- Dispatch from a thin controller and return the query result or the new id.
Guardrails
- Commands return nothing, or at most the id they created.
- Queries have no side effects, so they can be cached and retried.
- One handler per message; no handler dispatches back onto the bus it serves.
- Read models for complex queries are optional: add them when a query outgrows the entities.
Progressive disclosure
- Use this file for execution posture and risk controls.
- Open references when deep implementation details are needed.
Output contract
- Commands, queries and their handlers.
- The bus configuration and its middleware.
- Handler tests, and a functional test through the controller.
References
