Validation in a DDD world

It’s a common question, “Where do I put validation?”  Simple answer: put it where it’s needed.

But it’s not just a question of “where”, but of “when”, “what” and “why”.  If we treat our entities as data holders, we might think to put all of our validation there, in the form of reactive validation, where the entity is allowed to be put into an “invalid” state.

Validation depends completely on the context of the operation you’re trying to perform.  If we start looking at command/query separation and closure of operations not only on our service objects but our entities as well, we can treat our entities with a little more respect and not drag them around into areas they don’t really belong.  Simply put, if we control the operation side of the equation, why in the world would we allow our entities to get into an invalid state?  Life becomes much more complicated if we start having “IsValid” properties on our entities.

Think about that question, “is this entity valid”.  You can’t answer that question unless you know the context for validation.  Are you validating for persistence?  For changing an attribute?  For changing state (in the state pattern)?  For ETL?

In our current application, we have at least 3 different well-known locations for validation:

  • On our messages
  • In a command object
  • In our entities, for ETL scenarios

For about 5 seconds we considered trying to combine all of this validation into one grand uber-validator rules engine.  Ha. ha. ha.

Worst-case scenario

In the absolute worst case, we would have validation on our entities.  Something like an “IsValid” property or a “Validate” method.  Because we need to make judgment calls on what you’re trying to validate, things can get messy.  If all of your validation is on your entity, why are you even doing the Domain Model pattern in the first place?  Validation directly on entities is more suited for CRUD-y applications, where patterns like Active Record are more appropriate.

If you let your entities become invalid, you’ve most likely lost the context of what operation was being performed on the entity on the first place.  An entity may change state for a wide variety of reasons for a wide variety of operations, so certain attributes may be valid in one operation and invalid in the next.

Imagine an Order class that has several valid states, New, Confirmed, Placed and so on.  Often, we’ll place certain validation in the context of state changes, such as when an order is New versus moved from New to Confirmed.

Suppose we want to require a PhoneNumber for New orders.  But someone comes in that literally does not have a PhoneNumber, which our sales rep confirms through an email.  The Confirmed Orders are therefore allowed to have a blank PhoneNumber.  Are we supposed to capture all of this in a single Validate method?  I certainly hope not.

If you have to put validation on an entity, make sure you capture the context of what the operation the validation is operating against, likely in the name of the method.  For loading or ETL scenarios, I could imagine an IValidateForLoading interface that entities could opt-in to, just in the case where we don’t have control over hydrating the entity from bad data.

Thinking operationally

Instead of thinking of changing state on an entity, we need to move up to a higher level of command/query separation, where we perform and execute commands on one or many entities.  Am I performing validation, or reporting the result of an operation?  Lately, I’ve tended to go with the latter.

In that case, validation can take many forms.  I can use Castle Validators on my message object, to ensure that certain fields are required, this date can’t be in the future, and so on.  In my Command object, I’ll do further business rule validation, where I might need to coordinate between several different entities to determine if this operation can be performed successfully.

And that’s where I think we should move towards in terms of validation.  Instead of answering the question, “is this object valid”, try and answer the question, “Can this operation be performed?”.

Because our command objects know answers to all of the “Who, what, why” questions, they are in the best position to perform contextual validation based on the operation the user is trying to execute.

Validation doesn’t belong in one place, nor should they be constrained to one technology.  Validation belongs as close to the operation being performed as possible, to minimize risk of contaminating our entities with bad data or blurring its cohesion.

Summing it up

If I could look back at one thing that improved my take on validation the most, it’s adherence to a closure of operations.  I’d encourage you to go back to those sections on command/query separation and closure of operations in the Big Blue Book.  Once I adhered to those two concepts, validation was merely another step in reporting the success or failure of an operation, and like many good simplifications, a host of symptoms I mistook for separate diseases just went away.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Domain-Driven Design. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Michael Hart

    “If all of your validation is on your entity, why are you even doing the Domain Model pattern in the first place? Validation directly on entities is more suited for CRUD-y applications, where patterns like Active Record are more appropriate.”

    What about cases when you put your validation in your entity constructor? Do you consider that an anti-pattern?

    I’ve been doing this to ensure my entities aren’t created in invalid states and it’s been working fine so far – but I’m interested to hear if there are some downsides to this. (obviously it doesn’t cover all validation scenarios, but still… it is validation done on the entitiy)

  • http://www.lostechies.com/members/derick.bailey/default.aspx derick.bailey

    Thanks for this info, Jimmy! what you’re saying makes a lot of sense, and helps to answer some of the questions i posted, and validates some of the things i’ve been thinking and trying recently. i definitely need to go back and read up on the command query separation section.

  • http://www.lostechies.com/members/bogardj/default.aspx bogardj

    @Michael

    It works inasmuch as the parameters communicate what is needed to create a transient instance. I’m not a fan, however, of exceptions telling users what is invalid, as it’s often input from a UI.

    I’ve gone back and forth from a ctor taking the required parameters. I think it’s just not a binary decision though, it really depends on the operations you need to support.

  • http://www.lostechies.com/members/seanbiefeld/default.aspx Sean Biefeld

    Cool beans. Your post has led my mind in some new directions regarding validation, I’ll be sure to read the suggested material, hopefully that will help to further illuminate my understanding.

  • Dennis Kozora

    After reading the numerous articles/comments etc from Derick, Sean etc. I figured I’d share the current approach I have decided to follow.

    First, the methodology I currently use has grown from the concepts JP Boodhoo has presented in the past. Furthermore, I do not like attribute driven validation frameworks nor do I like IValidatable.IsValid methods in my entities.

    Simply, I prefer just to have validator classes IValidator with Validate(T entity). These validators can then be injected into my services, presenters etc. Simplifies testing and makes the design pluggable.

    In my experience, coupling the validation into an entity can “paint yourself into a corner”. Take for example an Event Management system. Say you have a Registration aggregate. The Registration could be validated differently based upon its state. For example, consider the following progression of the registration in the enterprise: pending->processing->approved->imported into CRM. Each one of those “states” would likely require different validators and different validation logic. With IoC containers, its easy enough to load a validator based upon an entity state.

    “In an attempt” to manage “reactionary validation”, I follow an implementation which leverages “validation rules”. Those rules objects ultimately include lambda expressions, descriptions, names etc. The validators would then just leverage those rules inside its Validate method.

  • Michael Hart

    @Jimmy

    Indeed, and I’m not creating my entities from my UI, so I don’t run into this issue (nor am I using exceptions, preferring a Notification approach). I tend to have UI validation as close to the UI as possible, so I end up in a similar situation to what you’re talking about with multiple validation points – still trying to get comfortable with this approach though.

    I find it useful to have the validation on the constructor to ensure that re-hydrated entities and those created within the domain itself are always in a valid state. With the IValidateForLoading approach you were discussing, how does this work in terms of creation? Do you just ensure that you call the appropriate method during the constructor? Or is this some sort of post-loading hook for an ORM?

  • Michael Hart

    (also forgot to point out that for complex creation scenarios, a fluent Builder approach has worked well for us too – this gives you more flexibility over just having a constructor – and child entities, related entities, etc can be validated too)

  • http://jonathan-oliver.blogspot.com/ Jonathan

    Jimmy,

    For your next post, I would love to see a quick-and-dirty C# example outlining the concepts above for a common, everyday situation, e.g. ChangePassword or some other well-known scenario. Specifically what I’d like to see is how information relating to invalid inputs, etc. flows back to the UI.

    Regarding the “Closure of Operations” you mentioned, from what I remember this is a way of saying “XYZ in XYZ out”. This makes it sound as like you’re passing a simple DTO as a parameter of the command object and then evaluating a Boolean on a returned DTO of the same type for success/failure as well to determine which values on the DTO are invalid and/or missing.

  • http://www.lostechies.com/members/bogardj/default.aspx bogardj

    @Michael

    We don’t really use it for creation, but that’s just us. Creation comes through a specific operation from the user side, so a factory or something similar is where we usually go.

    @Jonathan

    Closure of operations definitely needs its own post. Thanks for the suggestion!

  • T Moriarty

    @Dennis Kozora,

    “With IoC containers, its easy enough to load a validator based upon an entity state.”

    Are you implying that you are placing business/validation logic inside your IoC container?

  • http://justrudd.org/ Justin Rudd

    Hey Jimmy,

    I’ve been trying to wrap my head around the validation concept.

    For example, I’m working on a system right now that tracks build numbers on products. I have a business rule that states numbers can’t go backwards. For example, I have product A which is version 1. Bob goes and makes it version 3. Alice comes along and tries to make it version 2. In my mind, this is clearly a business rule that belongs in the entity representing the product. But I need to communicate with Alice that she tried to “move backwards”.

    Right now, the product entity simply throws an exception. My application service knows how to handle that exception. But this feels like using an exception for flow control which is a huge smell to me.

    I’ve seen mentioned in several places a “Result” object. Is this basically a local context object that collects data as the domain is executed?

  • http://www.lostechies.com/members/bogardj/default.aspx bogardj

    @Justin

    OperationResult is just for us a result of an operation. It has a Success property and an ErrorMessages property, as well contextual information.

  • http://justrudd.org/ Justin Rudd

    @bogardj,

    How do you get the OperationResult back to the application service? Return it from the domain method? That doesn’t seem likely as you’d be constraining your domain model. Is it similar to what Udi defines in his “domain events”?

  • http://jonkruger.com/blog Jon Kruger

    I’m not sure I see why it’s such a bad thing to have validation in the entity objects.

    I’ve worked on a bunch of thick client apps. In these apps, the user can change data in numerous different places, as opposed to a web app where you’re going to call a controller method or post to a page, etc.

    Even in a web app (let’s say I’m using an MVC framework), if I put my validation in my controller action methods, it’s possible that more than one controller could edit the same entity object and that I could need to put the same validation logic in more than one place. In some cases, I can see why the controller validation method makes sense.

    I’ve always done the IsValid() on the entity that throws an exception when IsValid() determines that the entity is not valid. I’m open to other ways, but I haven’t seen anything else yet. I’ve done the IValidator thing that another commenter mentioned, although I don’t totally see what I gain from doing it that way (at least for 95% of validation situations).

    If you have a better way than the way I’m doing it, I’d be interested in that post and specifically why you did it a certain way.

  • http://colinjack.blogspot.com colinjack

    Not sure I agree with this post. You describe the validation within the domain as if its an awful idea and the examples you give make it sound ridiculous and not consistent with DDD but I don’t think thats in any way true:

    > If we treat our entities as data holders, we might think to
    > put all of our validation there, in the form of reactive
    > validation, where the entity is allowed to be put into
    > an “invalid” state.

    Not sure thats true, if you view your entities as behavioral then you ask them to do X and they tell you whether they are happy with this (bearing in mind their current state).

    > If all of your validation is on your entity, why are you even
    > doing the Domain Model pattern in the first place?
    > Validation directly on entities is more suited for CRUD-y
    > applications, where patterns like Active Record are more
    > appropriate.

    It definitely wouldn’t/couldn’t all be in your entity, not sure anyone would argue that. I’ve had this discussion with Greg a few times and I see the point and I like the always valid idea but I don’t think its that or you’re doing CRUD and shouldn’t be worried about a domain model.

    > Are we supposed to capture all of this in a single Validate
    > method? I certainly hope not.

    Don’t think anyone would recommend. Entities co-ordinate behavior, they should be kept light so in this case the validation method(s) would at most co-ordinate other objects. So if your Order does go through different states then each state class could have its own validaiton rules.

    > If you have to put validation on an entity, make sure you
    > capture the context of what the operation the validation is
    > operating against, likely in the name of the method

    Absolutely, but thats the key point…validation is entirely contextual. In some cases validation is an either/or thing, an aggregate is valid or it isn’t.

    However once you get interesting behavior involved its “valid for X”, which is in my view where the always valid approach and the normal approach draw together.

    > And that’s where I think we should move towards in terms
    > of validation. Instead of answering the question, “is this
    > object valid”, try and answer the question, “Can this
    > operation be performed?”.

    Absolutely, but thats true whatever approach you take. And one way to help with this is to move behavior into your domain model, including your entities (again though, they probably co-ordinate the behavior rather than containing the code). In that context it becomes “are you prepared to do X, no, OK I’ll report notification of reasons why” and then “do X, oh you’ve told me in no uncertain terms your not happy to participate in that behavior”.

    > In my Command object, I’ll do further business rule
    > validation, where I might need to coordinate between
    > several different entities to determine if this operation can
    > be performed successfully.
    > And that’s where I think we should move towards in terms
    > of validation. Instead of answering the question, “is this
    > object valid”, try and answer the question, “Can this
    > operation be performed?”.

    Not sure I like that, that mindset totally turns your entities into data-holders. Absolutely I agree on focussing on behavior, and co-ordinating that behavior, but moving it all into commands…na.

    > Because our command objects know answers to all of
    > the “Who, what, why” questions, they are in the best
    > position to perform contextual validation based on the
    > operation the user is trying to execute

    If its cross aggregate then I’d use a service (which I assume is similiar enough to be the same idea), if its within the boundaries of a single aggregate then I think the aggregate root itself has all it needs as long as the method you call is correct (“DoX”).

  • http://www.lostechies.com/members/colinjack/default.aspx colinjack

    @Jimmy
    One question, when you talk about commands are you talking about command objects or command messages? I think its the former.

  • k03123

    hi jimmy,

    i read your post on validation at http://grabbagoft.blogspot.com/2007/10/entity-validation-with-visitors-and.html.

    i tried to post there and saw this blog and thought this is your new blog.

    anyway, in your example lets say Order has many OrderLines. for an Order to be valid for persistence, all the OrderLines also needs to be valid. now where does the validation of OrderLines belong?

    thanks

  • http://www.lostechies.com/members/bogardj/default.aspx bogardj

    @k03123

    In that case, if Order completely manages the OrderLines, it might belong in Order. Or, in OrderLine, and Order calls Validate on each order line. Either way, I’d let the Inappropriate Intimacy smell guide you.

  • Arnis L.

    Just ignored this problem all the time. Seemed fine to add it where it was needed.

    At least now I’ll know what to say next time someone will ask me this question.

  • JRod

    If you are enforcing command query separation so that your domain model only contains behaviors, why wouldn’t you put the validation within each bahavior method? I dont see what is wrong with this. I think each method should be responsible for checking whether that operation can be performed and returning a summary of problems to the caller. Putting it anywhere else seems like your domain objects can be manipulated with no restrictions and possibly put in an invalid state. Does anyone see any downside to this approach?

  • Pingback: DDD:关于模型的合法性,Entity.IsValid()合理吗? – 幸福框架 | 查问题