Validations and throwing exceptions in DDD?

Question

I have a question regarding validations and exceptions in DDD.

I have a ValueObject say, PasswordText which takes a string argument in it's constructor. Checks if the string matches the password criteria. If criteria, matches then the new object is initialized otherwise it throws an exception (DomainException).

The problem with this approach is, now, there could be many exceptions lying around in the Domain models that are ready to explode. It will be a headache for consumers of my Domain models to catch appropriate exceptions and act accordingly (like sending correct HTTP Status Code or something like that.)

My first question is how can I make this easy on them? Do I need to change my approach like using Notification Pattern or Either Pattern making it explicit for my consumers that this could return an error?

If the answer to above question is yes then how can I implement this approach for constructors? If answer of this question is Factories then sadly I have to create Factory for each domain model just for the sake of returning errors!

Also, I would like to add that the problem with Notification/Either Pattern is that, now my application code will be mixed with error handling code. How one should deal with this?

Is there any better way altogether for validations? Or How would you go about it?

Answer 1

You're right. You shouldn't offload responsibilities to the consumer for no reason.

So if you are inside one app, and it seems you are, there is absolutely no reason to abstract away parts of the application. If you know you'll have to return a HTTP error, do that. Yes, from the "domain" objects.

Purists will probably argue that domain and web must not be mixed. But let's be pragmatic about this. Why maintain (for a lot of additional work and ongoing maintenance) an abstraction that you're not going to be using?

The object should be responsible for validating itself, and if it is a part of a web-application, should be capable of indicating what's wrong to the user through the web interface if it needs to.

Instead of a Factory, I would probably use a factory method though. Separate factory objects are more useful if you need to use factories polymorphically.

Answer 2

Is there any better way altogether for validations?

TL;DR: Parse, Don't Validate.

---

... takes a string argument in it's constructor. Checks if the string matches...

This is a classic parsing example: you are starting with information in a general purpose data structure (a string), and trying to represent that information more specifically (a domain value).

As a rule, the logic to do this lives outside of your domain model.

It lives outside of your model for the same sort of reason that you are considering throwing an exception - we don't want to pollute the domain logic with a bunch of rarely used plumbing code.

One reason that this is confusing: we often see what look to be "validation checks" in the constructors/initializers of our value objects. That constructor code is usually an expression of a defensive programming guard: trying to ensure that the value can satisfy its contract by ensuring that its own inputs are within an acceptable range.

In other words, the checks in your value object constructors aren't there to mitigate against invalid inputs (that's a parser's job), they are there to mitigate against bugs in the parser.

---

Either pattern is one mechanism for implementing a parser branch.

Either<CompliantPassword, NonCompliantPassword> e = parse(rawString)

Alternatively, you could return a callable/interface, with the actual target function determined by what kind of instance was returned. In other words, you could design the code so that the branching logic is within the parser, instead of within the code that receives the parsed message.

I use "message" deliberately here - in this context, we're really talking about the in memory representation of the input, which probably includes one or more interesting domain values, but is not necessarily itself a domain value, but rather an element in your application model.