0

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?

Mohsen
  • 4,000
  • 8
  • 42
  • 73
  • I'm confused. I don't think it's bad to expose domain knowledge? Just that you want to keep the domain encapsulated so you can trust its invariants are hold true and make life easier for everybody. What will the wrapper accomplish? – Andreas Zita Jul 27 '18 at 19:32
  • @Andreas Zita: Passing value objects further than the service layer will end up shotgun surgery by domain model changes. The wrapper is actually a thin layer which converts the commands to value objects and maks the impossible. So 1- It reduces the number of tests that need to be done for validation. 2- Makes the model more documented. 3- It's more encapsulated. – Mohsen Jul 28 '18 at 09:23

1 Answers1

2

The value objects can have constraints such as for instance valid range on a integer or a regex on a string. If these constraints are validated and the values are passed around in the same compiled code boundary it should be ok. If you validate the values in another boundary and then just accept it as valid after deserialization, that would be leaky.

The commands just express intent. Its values are validated when handling the command with respect to the current domain state. Domain values are created and can both validate themselves internally or be validated by other domain logic.

Andreas Zita
  • 7,232
  • 6
  • 54
  • 115