title: Validation of Value Object with different stategies - password case
body: <p>I am designing library which is supposed to help me with designing domains in future projects. I made some basic Value Objects like EmailAddress or PhoneNumber. Those are easy. It starts to get problematic for me when such Value Object may have different ruleset that say if it is valid or not. </p>
  
  <p>Lets use <code>Password</code> as example here since it is actual reason of me writing this question. In previous projects I had password rulesets validated in <code>Password</code> construtor. But it makes this implementation project specific, and violates - I think - concern separation principle. </p>
  
  <p>I was thinking of Strategy Patten as solution here. But construction such VO in this way: <code>new Password("123456", new AwfullyLoosePasswordValidationStrategy())</code> sounds terrible to me. I was also thinking of static setter in VO <code>setValidationStrategy(PasswordValidationStrategy strategy)</code>, but this still is against concern separation and sounds really odd to me.</p>
  
  <p>So the first part of response is - I think - that Password should do only basic sanity check like <code>isNullOrEmptyString</code> and nothing more. But when I should do proper validation? During entity creation? Before persisting somewhere in service layer? Entity idea sounds not that bad for me, but how <code>setPassword(Password password</code>) would know about strategy I want to use? I try to avoid singletons in my projects and almost everything is done via DI there.</p>
  
  <p>tl;dr: Where should I validate Value Object that cannot be validated in its constructor?</p>