Entity Validation Ideation

Issue at Hand:

I have been recently sumo wrestling with the idea of entity validation in my mind. So far, the validation problem, which is like, E. Honda, has the advantage over my mind which is currently like, Chun Li. The worst thing is, all the other thoughts in my head are constantly struggling against my entity validation thoughts. As Homer Simpson says, “Every time I learn something new, it pushes some old stuff out of my brain”. Except for me E. Honda is doing his grab move, where he squeezes his opponent between his fat, and squeezing all of my current thoughts out of my brain. I don’t understand how sumo wrestling evolved as a sport, do they really have nothing to do in Japan. I bet it was the master creation of some drunken emperor. Umm, let’s see I want to watch two super fat dudes wearing nothing but a diaper try to knock each other out of circle with their bellies, muahahaha, they’ll be playing this sport for centuries!


I have been pondering about the idea of validation. Dictionary.com says valid is: “sound; just; well-founded, producing the desired result; effective”. Wiktionary’s valid definition in terms of logic is:“A formula or system that evaluates to true regardless of the input values.” When we think of validation in a programmers state of mind, the definition of valid in the logical sense, seems to jive the best. If x == y then it is valid if x != y it is invalid.

Entity validation is determined by business rules and processes. It appears that there are two fundamental approaches to validation, proactive and reactive validation.

Reactive Validation:

The most common way I have seen validation handled is the addition of an IsValid state to the entity. A good way of implementing this approach can be found in a posting by Jimmy Bogard. Whenever a business rule or process is broken the entity is no longer in a valid state. Then the user is informed of the problem in a different layer of the application. This form of validation is a very reactive way of handling validation. Meaning that it waits until something bad happens and then performs a function to cope with the contaminated actions. I don’t like this reactionary response, I would rather use something more preventative.

Proactive Validation:

What is valid validation? I wonder how many times I can use the word valid, or one of its etymological children in this post? What is a valid number of uses? I think the answer is 42.

So, is valid validation a proactive or reactive approach? I believe that proactive is always the best approach. My definition of proactive entity validation is never allowing an invalid entity to exist. This means removing the concept of an IsValid state on the entity. Once that is removed you don’t have to do an IsValid check everywhere in the application, which is my main gripe with the reactive solution. Is it valid for your domain to ever contain an entity in an invalid state, something about this scenario makes my skin crawl and stomach churn, or maybe it has to do with something I ate last night. Hmm, it was spicy so maybe. An invalid entity just seems like a bad idea, it is a treacherous force that will actively work against you like Saruman’s voice being cast across middle earth. I think being proactive is a much cleaner approach, and will cleanse your domain of IsValid checks. Wow, that is just a proof less rant.

Now the question is, what’s the best way to implement such a proactive solution? That’s the E. Honda I have been wrestling with. Let’s go over the broad definition of proactive entity validation. An entity cannot be created if it does not meet the business rules. Once we have a valid entity it cannot be modified unless the modifications satisfy the business rules. The stumbling block arises when your entity’s validity is based on a certain context. For example, it is valid to have a physicians drug order without a signature. When the process requires that the order to be sent to the pharmacy, the order is only valid when it has a signature. Ah, now the proactive solution becomes tricky because valid is defined by context. Following the proactive approach I could not create the entity without a signature, because it would be an entity in an invalid state. The only solution that I have thought of to this is having a drug order without the signature and a drug order request that inherits drug order and has the signature. The pharmacy then receives that drug order request with the signature on it.


I have not yet fully fleshed out the details of how exactly this would be implemented. I hope to hammer out a spike with a spiked drink. I do believe that using a proactive approach to entity validation falls more in line with domain driven design by having a tighter coupling to the business language. A drug order does not need a signature to exist. A drug order request with a signature fulfills the need of the drug order being sent to the pharmacy.

Be a proactionary and not a reactionary.

About Sean Biefeld

Hello all, my name is Sean Biefeld. I graduated from Baylor University with a BBA in Management Information Systems. I am currently working for Headspring . I have been a developing software professionally since 2004. My primary development focus is on HTML, CSS, JavaScript and C#. This blog is a forum for me to post my experiences, ideas, rants, and thoughts as I traverse the mountain of life.
This entry was posted in Domain Driven Design, Entity Validation. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Sadek Rady

    I think that “Is Valid” is not an intrinsic property of an entity. It is a relation between an Entity and a process or a service. The same entity with exactly the same state may be valid for certain processing and invalid for another type of processing.

  • joe


    Then it would be another entity.

  • @sean,

    you asked a question via twitter over the weekend. something to the effect of “what’s the difference between validation and business process or business logic in the domain model?” … i think that’s a fair summary of the question.

    for me at least, the difference is implicit vs explicit validation. you need to have valid data (explicit validation) before you can run a process. the process itself, is “valid” and produces “valid” results, assuming valid input. i consider this to be implicit validation.

    i think Jimmy said it best in his commentary on validation, over the weekend (http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/02/15/validation-in-a-ddd-world.aspx):

    “Instead of answering the question, “is this object valid”, try and answer the question, “Can this operation be performed?”. ”

    this is the direction that I have been heading in the last few days, leading up to these conversations. it seems to be working pretty well, so far. instead of littering my entity with ‘isvalid’ properties, i end up with services that say (in the case of needing to save the data to a dabase) something like “CanSave”. By moving the “is valid” check into the context under which validation must occur, we can simplify the entity and provide a replaceable / plugable solution for validation.

    the real problem after this is determining what is context dependent validation and what is truly the core needs of the entity or aggregate. if we’re not careful, we’ll end up in situations where we create anemic domain models simply because we want to move *all* logic (implicit and explicit validation) out into services. I’m having a hard time combating this. it’s hard to find the balance.

  • @Sean,

    Also – in the case where you would want to create a new entity type based on the “state” of the data – that is, a “SignedDrugOrder” vs a “DrugOrderRequest” or something similar… I agree with the principle behind this, but I think we disagree in how we achieve this.

    I’m not necessarily going to create an class hierarchy with inheritance to achieve this. Although I won’t throw this out as an option. There certainly are times when this is desirable. It always comes down to the needs of the system being built. Rather, I like to employ the State Pattern for this type of need, which by definition is “a clean way for an object to partially change its type at runtime.”

    … just some additional things to think about. there are so many ways to accomplish the same things in software. I’m very interested in seeing where you take all of this info and how you apply it in your code, moving forward.

  • b9CEwY ffkjelkrlbeb, [url=http://xkpcnazhyxfo.com/]xkpcnazhyxfo[/url], [link=http://ojuaedsdlkqy.com/]ojuaedsdlkqy[/link], http://nxazekgdeqht.com/

  • Wait how can someone comment and rip apart Sean’s case with Reactive and Proactive Validation without coming up with a more viable solution. To me, this is why one should make an honest attempt in not disrespecting someone who obviously has more skills in code than you do. I’m going to look and see how these reflect on what I’m doing along w/ Mr. Bogard’s post.

  • There are different flavors of validations. We have garbage validations (don’t allow bad data into a field) and relational validations (ensuring a proper multi-model construct where things are properly related in a graph) and business rule validations (particular to what makes sense in our domain’s workflow). Consider during a user session a user will have this interim state where he’s building up the transaction data. During the entire interaction as he moves from start to finish, we are at many times in a broken state violating rules on these three levels.

    Over what construct are you proposing your proactive validations be run? Are they being run over the controls or over some data model that is built up behind the controls?

    In a CRM, we have customer records, contact records (emails, phone numbers), address records, and purchase order records which themselves have line item records. Our business rules state: we never create a customer record until we have their first order and a customer must have at least one point of contact and one address. For a customer service rep to take a sales call, he has to build up that first transaction. From a human standpoint there is no way he can enter all these parts simultaneously, so he has to build up that transaction into an acceptable state. That build up must occur somewhere. Where? I’m assuming a data model. I’m assuming we run our validations over that “working” data model before we persist it.

    However, remember that during the build up of the transaction we have partial data that is not ready for a commit. In my mind that working data model is the source from which we persist. Are you recommending that we have a clean model that is never in an interim, broken state and a separate working model that may be? And if so, won’t reconciling those two representations pose a huge synchronization mess? I need a little help in realizing the semantics of how one might implement proactive validations. I have always allowed the working model (the one being built up in the session) to exist in a broken state. I just required that the state be fixed before a commit.