34

I often see the term Invariants in DDD. Here Dino Esposito talks about it. If I look at the .NET library, I see a ValidationAttribute class. Are Invariants and validation rules the same? For example, can I say 50% discount is available only if the order total is more than $250 is an Invariant?

Or are they different where Invariants are to protect an object from becoming invalid and validation is to check the validity of the object even after it has changed it's state (it can be in a valid or invalid state)? In the above example, if I use invariants, I check for the invariant before updating the discount and in the case of validation, I apply the 50% discount and then check for the validity (the object is already is in invalid state).

wonderful world
  • 10,969
  • 20
  • 97
  • 194

2 Answers2

34

Absolutely, validation is the process of approving a given object state, while invariant enforcement happens before that state has even been reached.

A corollary is that invariant enforcement is best performed by the thing that is being mutated (or created) itself, like a self-protection reflex, whereas validation is usually done by a third party.

The Always valid school of thought advocates the use of invariants over validation. I think it goes perfectly with DDD and Aggregates.

guillaume31
  • 13,738
  • 1
  • 32
  • 51
  • 4
    There is however some people that will not consider some basic validation rules as domain invariants since they are rules usually derived from technical constraints. For instance, the maximum length of an email address could not be considered as a business invariant by some DDD practitioners since the business doesn't care about the length of an email, but to be practical a technical constraint has to be set (e.g. using `varchar(500)` in the DB since you couldn't use `varchar(max)` for every field or the maximum row size of each DB would be overflowed). – plalx May 12 '15 at 14:48
  • 1
    Therefore, one could argue that `email.length <= 500` is not an invariant and could decide to delegate the check to the database. However, most DBs wouldn't even tell wich column overflowed, which could be an argument for enforcing the rule within the domain. – plalx May 12 '15 at 15:10
  • Since that differentiation is clear between 'invariants' and 'validation', can 'invariants' be called 'specifications' also? I'm thinking more in the line of testing the domain objects against the 'invariants'. – wonderful world May 12 '15 at 17:52
  • 6
    @wonderfulworld I prefer "Business rules" as a name.In the end is all about keeping an object in a valid state. Validation usually handles data formats which can be part of a business rule. As a thumb rule: you use validation to ensure the input data is in valid format, then the business rules decide how/if the input changes a model. – MikeSW May 12 '15 at 19:13
  • 1
    What I have seen quite often is that the architects from Europe use the word 'Invariants' while the architects from the United States use the word 'Business Rules' in their writings. The intention seems to be not to put an entity in an invalid state. – wonderful world May 13 '15 at 10:32
  • @MikeSW, +1 for "As a thumb rule: you use validation to ensure the input data is in valid format, then the business rules decide how/if the input changes a model.". This comment helped me to understand validation in CQRS. If you would like to answer my question here, then I will give some credit: https://stackoverflow.com/questions/50759872/should-i-ignore-the-guidance-and-avoid-putting-validation-in-the-command-objects/50761003?noredirect=1#comment88533124_50761003 – w0051977 Jun 08 '18 at 14:34
7

Yes, I think so

In DDD, validation rules can be thought as invariants. The main responsibility of an aggregate is to enforce invariants across state changes for all the entities within that aggregate.

You can refer more info in this page

Wolf
  • 6,361
  • 2
  • 28
  • 25