* The Execute / TryExecute pattern works best for task-based scenarios.
* For CRUD scenarios, you need to choose between Execute / TryExecute and validation in application services. The choice comes down to purity versus ease of implementation.
When putting the basics above together, you might consider the strategies below.
### For mutable or context-dependent objects
Use strategies for validations **after** object creation
* The Execute / TryExecute pattern works best for task-based scenarios.
* For CRUD scenarios, you need to choose between Execute / TryExecute and validation in application services. The choice comes down to purity versus ease of implementation.
### Immutable and context-independent objects
### Strategies for validations before object creation
Use validations **before** object creation
(first, you may want to validate as early as possible,
and secondly, it normally makes no sense to create object that never will be valid.)
* With (static/class level) validation AND factory method (for less complex cases)
* Essence pattern (for complex cases)
* Factory method AND validation method (for less complex cases)
* Note: validation method must be static/at class level
* Essence pattern (for more complex cases)
### Strategies for validation results:
* Detailed, containing a list of violations => for crud operations of multi-field input
* Simple: reporting one violation either with a simple or a generic message => for task-based operations (user just wants to execute a task and wants to know if the task was successful or not resp. why not)
### Validation results
Consider
* Detailed results (containing a list of violations)
* for crud-y operations e.g. when using multi-field input
* Simple results
* if detailed results would add no benefits, e.g. for task-based operations (if user just wants to execute a task and/or just wants to know if the task was successful or not resp. why not)
