* After creation (but before actual usage of the data)
### Validation patterns
* Validation on existing objects/states during business operations (i.e. after object creation) (see https://enterprisecraftsmanship.com/posts/validation-and-ddd/) :
* validate / isValid methods (backdraw: race conditions can lead to invalid state)
* in application services (backdraw: potential business logic leakage)
* TryExecute (backdraw: no CQRS separation: potential state change AND returning data (i.e. error message))
* Execute / CanExecute => call separately „Can“- and „execute“-method, (partial) state is stored locally which means no race conditions can lead to an invalid state
* Validation during object creation (avoids invalid objects), without public validation method
* In constructor
* In factory method (e.g. create method)
* In Factory
* In Builder
* Validation before object creation with public validation method (avoids invalid objects, allows CQRS and detailed results):
* With (static/class level) validation AND factory method - (https://savoiragile.com/2012/06/28/english-object-validation-on-immutable-objects/ & https://reflectoring.io/java-immutables/ )
* Using Essence pattern (https://stackoverflow.com/questions/9776193/good-practice-to-validate-immutable-values-objects )
* Also Factory and Builder pattern could be added with a validate method (https://stackoverflow.com/questions/16221010/should-the-factory-pattern-contain-validation-logic ), but does not seem very common
* 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.
* 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)