On one hand, the invariants should be protected (To make invalid states impossible early and preferably at compile time rather than run time), and on the other hand, passing domain knowledge out of the domain is wrong.
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.
The only solution for both protecting the invariants, and avoiding the domain knowledge from leaking the domain boundary (encapsulating the domain model), seems to wrap the aggregates in a command-to-value-object-mapper.
I'm using CQRS along with ES.
Is it ok to have a wrapper as a command-to-value-object-mapper around my aggregate roots? Is there any other solution?
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.
Nothing in DDD says that you shouldn't pass domain knowledge around. Quite the contrary - the Ubiquitous Language means that domain knowledge will be everywhere from front end to repositories.
You might mean domain logic instead.
Commands don't include domain logic. They are dumb data structures that describe user intention and the data associated. They don't implement anything. So if you use commands properly, you're good to go - no domain logic leakage.
Can command handlers be separated from aggregate roots and value objects be composed at the command handlers in CQRS?
but it would be too long. And the body is supporting it. Find the phrase: wrap the aggregates in a command-to-value-object-mapper
from the page. — Jul 23, 2018 at 09:17