Over the past few months I have been trying to wrap my head around the concept of user input validation and operational validation and how to best handle it. In many regards, it's a domain concept so it should be in the domain. But at the same time, it felt weird to put the validation logic inside of an entity object in a highly reactive, IsValid fashion. This smacks of doing CRUD operations on a DDD object.
As I have grappled with this problem I have noticed a few more posts on the issue. Rinat Abdullin has an intriguing post on the matter. In the end, he raises some valid points--and I like the visual/GUI aspect of what he's doing.
The catalyst that started driving the concept home for me was Jimmy Bogard's post on Validation in a DDD world. He confirmed to me that we don't want validation in the entities--which I already knew, but couldn't quite put my finger on. He then went on to discuss that we want to encapsulate the validation into our command objects and that we should be thinking operationally and in terms of command/query separation. He then referenced the Blue Bible--Evan's DDD book.
After re-reading a few sections in my copy of Evan's book, I wasn't able to find as much on command/query separation as I had wanted--perhaps because I wasn't looking in the correct spot. [UPDATE: It's Chapter 10, Side-Effect Free Functions] I did a quick Google search for "domain driven design command query separation" and found an excellent--and very recent--InfoQ video clip of CodeBetter's Greg Young. This is where things started to get exciting as they began to gel.
Greg talked about how he had a "write-only" domain model with command objects that would represent real world commands. [In the stereotypical case, things like ChangePassword, PlaceOrder, etc.] The idea was that the domain objects didn't really have getters and setters--they simply had commands performed on them in a very Tell Don't Ask manner.
Then, to populate a screen or web page with pertinent reporting or display information, a completely different, query-object, DTO-based subsystem was used. These query objects went straight to the data store--through an appropriate layer of encapsulation--to get all the necessary data to populate the screen. This subsystem handled all reporting needs as well as infrastructure concerns like paging of results.
Greg went into some detail regarding how his system was structured using event sourcing, which seemed to be an incredibly powerful way to create a system--especially the ability to snapshot, replay and rewind a set of changes to a point in time.
All in all, it was a fascinating journey of discovery. I've known about a few of the concepts implicitly--as sort of a gut feeling--but having them made explicit helps bring about a significantly increased level of understanding.
To conclude on validation--how is it done? Per my understanding at this point, the command object is responsible to perform the validation. Okay, easy enough. How is that validation made available to the user in the GUI? That's the part that I'm not 100% clear on. There appears to be several options. The first is that we return a simple DTO from the command object reporting on the success or failure of the operation with a set of validation errors included. The second option seems to be to fire some kind of event which includes a set of errors or to have a unique event per error.
I'll post more as I dig a little deeper.
UPDATE: This is a really good post from Derek Bailey, more especially the comments from Scott Bellware.