Re: Should the "command" method do the validation?
"Caleb Cushing [email protected] [domaindrivendesign]" <[email protected]> Tue, 03 Nov 2015 14:43:12 +0000
| Newsgroups | gmane.comp.programming.domain-driven-design |
|---|---|
| Message-ID | <CAAHKNRHuDqPT2xjcU6gUBXy5P0XWEBNfQWLYZdOD+TdDMQnuag@mail.gmail.com> |
>
> Should validation in a domain Entity be implemented as separate method or
> as part of the Entity state changing method?
>
Yes, and possibly another option if there's a validation framework
(depending on complexity)
Seems to me like you might be taking CQS a little too literally. It
doesn't state that commands cannot do queries only that you have a method
separation, and in fact I would argue that its intent is more that queries
should not do commands (effect a change of state). You write your queries
into separate methods so they can be tested and reused without side
effects. You can then use them inside of methods that have side effects.
I dislike the special return code wrapper, though it's better than using
return codes. This is one of those holy war things, the exception is
probably better. Though I would use a subclass exception CannotFitBooking
(or similar), and make it checked (or at least part of the method signature
assuming a feature of your language), so controllers calling your method
have to deal with the domain constraint violation which is not a programmer
error.
you might consider this instead
void add( Booking booking ) throws CannotFitBooking {
this.checkFits( booking );
bookings.add( booking );
}
void checkFits( Booking booking ) {
Objects.requireNonNull( booking );
... more validation logic that throws CannotFitBooking
}
--
Caleb Cushing
http://xenoterracide.com