Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
DDD: Invariants or Contextual Validation?

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.

del.icio.us Tags: ,,

Posted 03-11-2009 9:10 AM by Jak Charlton

[Advertisement]

Comments

Alastair Smith wrote re: DDD: Invariants or Contextual Validation?
on 03-11-2009 6:41 AM

Hi Casey

You state that, "An invariant is something that cannot be changed about our object ... [such as] a CustomerNumber, a FirstName and a LastName", and that, "these must always be valid individually and when evaluated together".  I agree with that last part in principle, but I do not agree that FirstName and LastName are invariant.  

For example, what if a typo is made when entering the first name?  What if the customer is a woman and gets married sometime after giving you her name?  In both cases, the FirstName or LastName fields will need changing, and in your model this would require the creation of a new Customer with a new CustomerNumber (as these fields can only be set as parameters to the constructor).  This would likely lose the customer's historical data and/or result in duplicated data.

Apologies if I've missed the point here :-)

Alastair

PS: I'm really enjoying this series!

Jak Charlton wrote re: DDD: Invariants or Contextual Validation?
on 03-11-2009 6:54 AM

Alastair

Apologies if again I confused ... the properties mentioned in this case are Invariant in that they must always remain valid, and without them being valid the Customer can not be valid - they are not Immutable, which would imply they cannot be changed

What cannot be changed about an Invariant is the rule - it must always be evaluated to be true

John Billy wrote re: DDD: Invariants or Contextual Validation?
on 03-11-2009 8:08 AM

Contextual validation... I think

Jimmy Bogard wrote re: DDD: Invariants or Contextual Validation?
on 03-11-2009 8:55 AM

This is why I can't stand the "IsValid" method for non-invariants.  IsValid?  Is valid for what, under what context, what operation?  An order can be valid for processing, or valid for persistence.  Two different contexts with completely different business meanings.

Jak Charlton wrote re: DDD: Invariants or Contextual Validation?
on 03-11-2009 9:12 AM

Thanks Jimmy - that helps clear it up even more ...

Indeed there is no such thing as "IsValid" - there are such things as "IsValidForReconcilliation" or "IsValidForDiscountCalculation"

I think the point about invariants I was trying to make is that done right, the entity will always be valid for persistence - it can never be otherwise - but the contextual stuff may mean it is not valid for every scenario

DotNetShoutout wrote DDD: Invariants or Contextual Validation? - Casey Charlton - Insane World
on 03-11-2009 9:13 AM

Thank you for submitting this cool story - Trackback from DotNetShoutout

new ThoughtStream("Derick Bailey"); wrote Proactive vs Reactive Validation: Don’t We Need Both?
on 03-11-2009 9:54 AM

Update: There’s a wealth of knowledge out there that I just haven’t been aware of until now. Thanks to

Arjan`s World » LINKBLOG for March 11, 2009 wrote Arjan`s World » LINKBLOG for March 11, 2009
on 03-11-2009 10:57 AM

Pingback from  Arjan`s World    » LINKBLOG for March 11, 2009

Reflective Perspective - Chris Alcock » The Morning Brew #305 wrote Reflective Perspective - Chris Alcock » The Morning Brew #305
on 03-12-2009 3:01 AM

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #305

Pages tagged "insane" wrote Pages tagged "insane"
on 03-12-2009 11:34 AM

Pingback from  Pages tagged "insane"

TrackBack wrote Domain Driven Design
on 01-17-2013 1:38 PM

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)