Greg Young made a good point to me regarding my last post about Validation, Consistency and Immutability, specifically around validation – even more specifically he thought I may have simplified it too far.

I was trying to cover the basics of the subject, but may have made the bit around validation a little fuzzy – over the series I have been deliberately taking baby steps so as not to lose anyone early. A lot of the confusion I see around DDD is largely around people jumping right into the deep end without the basic stuff clear first.

The last blog post had a very long section that I removed – it was entitled “Invariants” – but after I proof read it, it made absolutely no sense to me, so I figured it would make no sense to anyone reading it either. Turns out, by removing it, I may have made less sense too! I’ll try again. (disclaimer: suffering from really rotten head cold, so this may make no sense either – feel free to tell me if so)

Invariants

As the name says, an Invariant is something that cannot change – it cannot be varied.

Greg’s point was:

not to get philosophical but... consider Plato's ideals. What attributes of an object make it that object? Must be valid!

This is what I believe Greg likes to refer to as an invariant – or what I was trying to explain around using constructors to enforce “valid” entities.

This then splits our validation into two distinct camps – the invariants and the contextual validation.

An invariant is something that cannot be changed about our object – using our previous example, it must have a CustomerNumber, a FirstName and a LastName, and these must always be valid individually and when evaluated together – there can be no variance from that rule – and so we enforce that by only allowing setting these via the constructor or a strongly named method. No Customer can ever exist without these being valid.

The things that make our Customer a Customer are those attributes.

Contextual Validation

In my previous example, I used the concept that a Customer may have a Policy – let’s say this is an insurance scenario. I also said that the fact that the Customer didn’t have a Policy, it didn’t mean the Customer was invalid, it just meant we would have to have some kind of validation at the point we needed to have a Policy

This is what I believe Greg refers to as Contextual Validation – when we use the entity we may need to validate it is in a fit state for the specific operation we wish to carry out, but we shouldn’t have to validate everything about it.

In Conclusion

Greg said he is doing up a blog post of his own on the subject at some point in the future, which is good as the issue of validation seems to be a sticking point in DDD and in development generally. I definitely look forward to reading it. Keep an eye on his blog at Codebetter for it.

By defining the types of validation more accurately, we can try and avoid some of the confusion which I was introducing in my last post on the subject.

Invariants are the rules that cannot ever be broken about an entity, aggregate or VO

Contextual validation is a check that for a particular action, the entity, aggregate or VO is valid at that point.