Può comandare che i gestori siano separati dalle radici aggregate in CQRS

On one hand, the value objects protect our domain invariants at first place, on the other hand using them as commands or as it's properties equals passing domain knowledge around.

Niente in DDD dice che non si dovrebbe passare la conoscenza del dominio in giro. Al contrario, l'Ubiquitous Language significa che la conoscenza del dominio sarà ovunque dal front-end ai repository.

Potresti voler dire dominio logica invece.

I comandi non includono la logica di dominio. Sono strutture di dati stupide che descrivono l'intenzione dell'utente e i dati associati. Non implementano nulla. Quindi se usi correttamente i comandi, sei a posto - nessuna perdita di logica di dominio.

On one hand, the value objects protect our domain invariants at first place, on the other hand using them as commands or as it's properties equals passing domain knowledge around.

Non sono d'accordo con questo. Puoi fare tutto ciò che ti serve con i tuoi Comandi ed Eventi, persino salvarli se lo desideri. Sono immutabili e non contengono conoscenze di dominio. Rappresentano l'intento e il fatto.

Passare alla conoscenza del dominio potrebbe significare che il codice / la logica del dominio si diffondono in livelli diversi dal dominio, ad esempio nei servizi di applicazioni o infrastrutture, il che è davvero negativo.

La soluzione è mantenere il codice di dominio che gestisce gli invarianti (la logica del dominio) all'interno degli aggregati (questo include la radice Aggregate, le entità nidificate e gli oggetti Valore). A proposito, è possibile passare anche gli oggetti Value, come argomenti alle chiamate di metodo; sono anche immutabili, come un'indicazione che modificarli non è permesso o è inutile.

Is it ok to have a wrapper as a command-to-value-object-mapper around my aggregate roots? Is there any other solution?

No, non ha senso. Inoltre, trasformarli in qualcos'altro li farebbe perdere l' intento , il loro aspetto più importante.