Architecture question for a Symfony/API Platform project using pragmatic CQRS / hexagonal architecture

[ahmed-bhs]

For a custom POST operation in API Platform, we often end up with this flow:

  ApiResource Post
  -> input: CreateSomethingInput::class
  -> Processor
  -> CreateSomethingCommand
  -> CommandHandler
  -> Domain

In many cases, CreateSomethingInput and CreateSomethingCommand have exactly the same fields and the same validation constraints. The processor then mostly does mechanical
mapping:

  $command = new CreateSomethingCommand(
      fieldA: $input->fieldA,
      fieldB: $input->fieldB,
      ...
  );

In that context, do you consider it acceptable to use the application Command directly as the API Platform input?

Example:

  ApiResource Post
  -> input: CreateSomethingCommand::class
  -> Processor
  -> CommandHandler
  -> Domain

With Symfony Validator constraints directly on the Command:

final class CreateSomethingCommand
{
    public function __construct(
        #[Assert\NotBlank]
        public ?string $name = null,

        #[Assert\NotNull]
        #[Assert\PositiveOrZero]
        public ?int $quantity = null,
    ) {}
}

The Processor would only add server-side context when needed, such as the current user, organization, tenant, IP address, etc., then dispatch the Command.

Pros I see:

• less boilerplate
• less duplication between API input DTO and Command
• less mapping with no business value
• the use case input contract is easier to read

Possible drawbacks:

• the application layer depends on Symfony Validator attributes
• the Command also becomes part of the HTTP contract
• if the API contract diverges from the use case later, we may need to reintroduce a dedicated API DTO
• it blurs the strict separation between HTTP adapter and application layer

What do you usually do in production Symfony/API Platform projects?

1. Always use a dedicated API input DTO, then map to a Command?
2. Use the Command directly as API Platform input?
3. Use a hybrid rule: Command-as-input when it is 1:1, dedicated DTO when the API contract diverges?
4. Something else?