Hi Greg,

I do strongly agree with you.

Just commenting on the following quote.

"This is referring to one type of validation that occurs within a domain. This is a validation to perform an operation. Generally speaking this type of validation is not performed by the object itself but is represented as observations of that object by another object. Jeff is right in that trying to make these things always valid makes no sense."

If we have object that can be valid in different states we can use the state pattern to do the validation in each different state. I still think we should validate an object in the constructor and as we perform operation like change address on an entity to stop an object from moving into an invalid state.

I have used the old isvalid approach before and you end up seeing checks everywhere for this in the service layer methods. I have found it to be annoying checking it everyone and it hurts when you forget to check it as it breaks code in other places that you have assumptions of things being in a certain state.

I would really love to get other peoples ideas and techniques and maybe share some code on the above.

Blair Davidson

Hi Greg,

I do strongly agree with you.

Just commenting on the following quote.

"This is referring to one type of validation that occurs within a domain. This is a validation to perform an operation. Generally speaking this type of validation is not performed by the object itself but is represented as observations of that object by another object. Jeff is right in that trying to make these things always valid makes no sense."

If we have object that can be valid in different states we can use the state pattern to do the validation in each different state. I still think we should validate an object in the constructor and as we perform operation like change address on an entity to stop an object from moving into an invalid state.

I have used the old isvalid approach before and you end up seeing checks everywhere for this in the service layer methods. I have found it to be annoying checking it everyone and it hurts when you forget to check it as it breaks code in other places that you have assumptions of things being in a certain state.

I would really love to get other peoples ideas and techniques and maybe share some code on the above.

Blair Davidson

I always thought people bottled up "Always valid" in too specific a context. Jeff is only arguing "always valid" is bad with entity invariants. We have more objects in the domain model than entities. We have value objects, services, components (transient state-based objects), Repositories, Messages, etc. All of these have "invariants". A BudweiserCommercial service would have an "invariant" that it can only register Clydesdale horses, for example.

Greg,

Trying to get a sense of what you mean by invariants. They are things that, when satisfied, mean the object simply can't exist, yesno? I.e. you don't *need* to write the test checking to see if a cyclops has two eyes because that case is not physically possible?

And the type of validation from Jeff's example, where you need a customer's name in order to fill an order, is a different type of validation? That is, the customer's name isn't an invariant.

Hi Greg,

Excellent article and I totally agree. I find the distinction you make between different types of validation particularly useful. There is a clear difference between an object that is not in a fit state for some purpose and one that breaks incontrovertible laws about what it means to be of that type.

Do you have any good 3.0 patterns around invariants? For immutable types I tend to have guards in the constructor. Where I have state modifying methods I sometimes factor to a private method. Still all a bit clunky though.

Gillian,

Jeff's argument that always valid is bad with entities is exactly the problem: there is nowhere it is more important in the context of invariants. To extend Greg's example. A Cyclops with two eyes is not in need of questioning to find out whether it can wear glasses. It is simply not a Cyclops, by definition and, at a code level, by invariant.

DDD, an aspect of which Jeff puports to be demonstrating in his post, and all OO modelling is based on the  pretty simple premise that the better software reflects the real world the more chance it has of meeting requirements for that world. Why would anyone prepared to put in the time and effort to apply DDD ever allow a Cylops with two eyes to exist? It is never valid. In any context. That is what  we mean by invariant. It always holds true within the given domain.

Jeff's example is the direct equivalent of the two-eyed Cyclops. I think this is the point he hasn't grasped. The fallacy he talks of is not a fallacy at all. It is a subtlety he has completely missed in what "always valid" means to the people who actually use it

The idea that there are contexts for validation is something I have struggled with before:

blogs.msdn.com/.../nullable-false-but-when-exactly.aspx

Looking forward to chatting about this.

Greg, I enjoy your writing.  I agree with you a lot.  But I'm going to stop paying attention to you until I see some source code.  Jeffrey releases plenty of it.  Where's yours?

I agree with Nate, most of us wanna see some piece of code, specially about CQS!

Please Greg, make us happy!

Sory bad english

Gutted, I wrote a sizable reply but I don't remember doing the 'captcha' (looks to much like a banner to me, isn't immediately obvious, ah well).

Basically I was saying that in terms of validation, entities already validate quite a lot by just being .net types, for example- we know an entity has these properties, and we also enforce how those properties look (int, DateTime, string - etc)..

It seems to me there are some universally correct validations for an entity, where any usual scenario would want these validations.. if not then you would probably want entities to be a property bag which seems scary.. it seems sensible that an entity should validate itself to these universal concerns (with compile time errors where possible, ie type correctness).

But that any additional concerns are concerns of a specific operation, and they should validate that a given entity satisfies their requirements.. my example was that if you passed a 'Comment' to presentation logic, it may only care that you have a Name, Body and a post date.. but passing a comment to the persistence layer would have different concerns.. that the comments date is now in the future (for example).

However you manage to generalize these validations is up to you..

Variants are good for things that the type system can enforce, thus getting compile time validation.. but most validation I think happens at runtime, but I think tools like code contracts could massively help push runtime concerns to compile time.

Jak w większości systemów budowanych w oparciu o DDD, tak i w naszym natrafiliśmy w końcu na problem

We recently came across a problem with validation of domain objects. A the begining I told programmers

Good post as always.

I would like to see a code example of this if possible. I sometimes find it hard to picture how the code would be. Could you do it for a simple example of a say a customer which has contact addresses and when editing a customer he/she must have details (title, name etc) and at least one contact address?

Hi,

Would be great to see some code of this, just a simple customer edit example.