Proactive vs Reactive Validation: Don’t We Need Both?

Update: There’s a wealth of knowledge out there that I just haven’t been aware of until now. Thanks to the many commenters of this post, other posts, and other conversations for the links and info. Here is a list of items that I’m finding to be very helpful in understanding what is only a surface level “validation” problem:

Update 3/3/2009 – additional info in the continuing conversation.

Update 3/11/2009


There’s a whole host of stuff out there linked from these articles and posts, as well. It’s obvious now that I have a lot to learn and think about, and I think I have a better sense of where I need to start looking. I also think that the ideas Sean Biefeld expressed about never letting an entity be in an invalid state are more reachable than I previously thought.


This post started as a comment in Sean’s post on Entity Validation Ideation but quickly grew. I’m hesitant to post separately because I believe the conversation should continue along the lines of what he was originally saying. There’s just so much junk tossing around in my head, though, I didn’t think it would be appropriate to post a 50 page diatribe in a comment. :)


A while back, I asked the question “Where does required info validation belong for an entity?” There were a lot of good answers to that question and my team and I took some very interesting directions based on those answers. However, I still haven’t had the ‘validation’ question completely answered in my mind. Fortunately, I’ve got the brains of my fellow Los Techies (and coworker in this case), to keep me from giving in to the entropy that wants to keep me mediocre.

I love the theory that Sean is talking about – especially when stated as ‘proactive’ vs ‘reactive’. I’ve had a hard time with this in practice, though. In the last few weeks – days, really – it seems to me that we need to have both proactive and reactive validation in our applications.

Being Proactive

The domain model that I create wants to prevent an object from being invalid, so I require a minimum set of information in my constructors, etc etc. This helps me prevent an object from ever being created in an invalid state. this is the proactive approach. I love this approach and I use it a lot.

Oh Wait, I Need Reactive

The proactive recently failed me, though. I had ‘the perfect’ domain model with the all the validation and rules composed in my entities, preventing the information from being added to the model if it was not valid. However, when I got to the user interface, I realized that I had a major design problem. The user interface is not ‘all or nothing’ scenario. The user is allowed (expected, really) to only provide one field of information at a time. After all, you can’t type into more than one text box at a time – unless you have multiple keyboards and multi-input capable systems. So, when a user is adding information to the inputs of the form, we need to have a reactive approach. We need to provide real time validation of what the user is putting into the system, so that they can be immediately notified of any errors in what they are providing. This reactive approach is needed because the user interface is entirely reactive to the user’s actions.

Proactive AND Reactive?

At the same time that we need both a proactive and a reactive solution, we want to adhere to the "Don’t Repeat Yourself" principle, encapsulating the validation logic into the appropriate location(s). If we require reactive validation in the user interface, and proactive validation in the domain model, how do we avoid breaking DRY?

On the surface, proactive and reactive validation seem to be at odds with each other – at least, they do in my mind. I don’t think they need to be, or should be, though. We just need to find the higher level order in which we can enable both. Unfortunately, I haven’t been able to do this yet – at least not in a way that really seems to satisfy me. I’m curious to know how others approach this situation. How do we balance this triad of need: Proactive, Reactive, and DRY?

I need some fresh perspectives on this, and I think Sean is starting out with some great ideas. Now if I can just learn to throw away my own bias to how I’ve already been handling this, maybe I’ll be able to learn something. :)

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs - the amazingly awesome podcast audio hosting service that everyone should be using, and where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in .NET, C#, Domain Driven Design, Principles and Patterns. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • I think the answer would be to still keep all validation logic in the entity, allow a service to handle specific validation requests needed to validate individual pieces for the UI. Don’t actually create the entity until everything needed to create it is valid. Then create the valid entity and do what ever you need to do with it. That way you can access the validation logic without creating an invalid entity.

  • DRY means not coding the same thing twice. It’s doesn’t mean not using the same abstraction in multiple scenarios and contexts.

    An entity a one pattern for use primarily in one corner of an application’s topology. When you start using entities as ubiquitous data objects, you’re inevitably going to find yourself in the ditch.

    There’s no one, universal, single approach to where to put validation. The answer is most certainly not that validation belongs in an entity because an entity is not a ubiquitous, mobile object, traveling all corners of an application’s topology.

    The real answer is much more involved, and much harder than the tragically-naive way that we often use DDD-light. And at the same time, it’s much simpler:

    Validation goes where it’s needed, but validation isn’t owned by merely one class of design patterns. You can, should, and must put validation where validation belongs without dragging along entities for the ride because it’s not the entity you always need, it’s the validation.

    When you convince yourself of the naivety that validation is a member of entities, and only entities own validation, you’re going to find yourself using entities in a lot of places that they don’t belong. And that is going to create a bigger mess and bigger trouble than the trouble you think you’re avoiding by adopting the excessive and accidental simplicity of making entities be the sole owner of validation.

  • @scott

    I understand that a lot of validation is based on the context in which the system is currently running. For example, we had a problem lovingly dubbed ‘The Z Problem’ about 2 years ago. This issue was centered around a user interface that would not allow a ‘Z’ code in an input box, by business rule. But when importing data from a specific external system, ‘Z’ was a valid and common code for that datum. The design, at the time, had “no z’s allowed” coded into the entity, which broke the import process. the ‘right’ solution at the time was to move that particular validation into a service layer so that the UI and the import services could act independently according to their own needs, yet consistently within the domain.

    I’ve also seen the problems that using an entity as a ubiquitous data transfer object + domain rules + everything else can cause. I’m dealing with that mess in my current application, by my own fault.
    i’ve been slowly but surely coming around to the realization that i need some sort of presentation model (call it what you wan… the ‘model’ that the UI interacts with directly) in many cases, and not a direct domain model access scenario. it’s this realization that is causing to start asking all these additional questions. I’m still having a hard time understanding, in concrete terms, what should be domain logic and validation vs presentation or other service logic and validation. there are some obvious black & white situations, of course. it’s not the extremes that i’m having a hard time with. it’s the subtle gray areas – the ‘what feels right’ areas – that i’m having a hard time with.

    i guess that’s the real crux of my questions – what is entity and domain service validation, vs. what is presentation or other API validation? The real problem is finding a consistent theory or guideline that crosses applications and technologies – even finding guidelines, principles, or theories to cross applications within c# seems to be elusive. i understand what you are saying, abstractly – but until i have a concrete implementation to use as an example, i’m going to have a hard time being able to apply that understanding.

    • didibus

      Maybe you need two entities? One which allow Zs and one which does not. They could even extend a common base if only the validation is different. But it still sounds that your domain here seems to speak of two cases of a thing, both identical in structure, but different in behaviour (validation being a kind of behaviour).

  • I also think you need to think about these things in two contexts. For the UI, you are talking about tying field level validations to your domain model validations. This just doesn’t work. Think about a three tier applications with web services. Sometimes your DTOs have different field names or do not even directly belong to an entity at all. In this case, you have no way to directly tie a UI field to a validation.

    In the context of submitting an entity, you can certainly run your business rules and return your validation information:

    ValidationSummary Insert(SomeInsertMessage m, out int? id);

    But in the context of input validations, I have yet to find an approach where this works nice. You could do some complicated scheme where you map a UI field to a validation error message that gets returned from the service and incrementally submit, but I doubt that would work very well in practice.

  • The problem is that you’re looking for a consistent theory or guideline that crosses applications and technologies. Not only does it not exist, but it doesn’t exist because it’s not necessary.

    The here is with DDD-light – when we think of our solutions in terms of concrete “Domain Entities” and “Services” and “Repositories” and “Specifications” and “Value Objects”. Programmers got a hold of these things and turned them into programmer artifacts. Got a namespace called “Repositories”? You’re in the ditch. Got a namespace called “Services”? You’re in the ditch.

    You need to do DDD as a domain-driven designer rather than a programmer. This means backing off the unconscious and utterly unproductive behavioral habits of programmers who turn every concept into a heirarchy that can be represented in code. When you can see domain-driven design in your code, you’re doing it naively, and that naivety means over-specialization and that means problems.

    DDD isn’t a guideline for coding. It’s a guideline for thinking. You need more content in the cabeza before turning thoughts into code. If you’re thinking “Entity” or “Repository” and that’s what ends up in the code, then there’s a whole field of work and thinking that represents multiple steps of software work that are simply awol from the process.

  • nightshade427

    Don’t bind your entities directly to the UI it makes life hard, use a UI model.

    Not all validation needs to go into the Entity. You have to think if the validation applies to entity in all cases. If so then by all means put it into the entity. If it is more related to how an entity is used in a service of some kind, then put it in the service. If it has more to do with how an entity relates to something else put it into a relational object of some kind. I guess what I am getting at is look at how the validation is used and when it applies and put it in the correct place to handle that.

  • Lars Mæhlum

    If you truly want to go far out on this one, why not use an Aspect Oriented approach to validation?
    If you make your DTO’s with validation attributes, you can easily tack on field validation logic in the View, while demanding that the mapping to your domain objects also validation the whole object before it is mapped.
    This way your domain objects stay clean, while you can ensure that all objects passing the DTO-DMO barrier are valid.

    Just my $.02

  • @all,

    Thank you all very much for your comments on these questions… in combination with Jimmy’s post ( I think I have a better idea of what I should be looking for / doing in my systems. As it turns out, I may have been going down ‘the right path’ already with my recent code. It’s always nice to be validated, though (punny, yes? :P )

  • Sean and I continue the conversation via our internal instant messenger client today. Just wanted to share with the rest of you. I’ve re-ordered some of the messages so they make more sense.

    Sean Biefeld:
    why not come up with a way to avoid doing the isvalid, cansave check, not worry if entity is valid, know if it exists it is valid

    Derick E. Bailey:
    because it’s not possible to do that.

    Sean Biefeld :
    well it should be

    Derick E. Bailey:
    by your own statement “know if it exists, it is valid”, you’ve already stated that validation has happened
    it just happened at construction
    the real problem with this, in c#, is that we can’t “cancel” object construction without throwing exceptions

    Derick E. Bailey:
    you can’t return null from a constructor
    i agree with that idea, but i think there’s a little more to it than just that
    that idea of “valid” is context dependent
    whether you are creating a new object for “SignedDrugOrder” vs “DrugOrderRequest”, or using a state pattern or isvalid flags – you are still doing the validation
    it’s just context specific validation
    you are validating that the drug order is signed by creating a “signeddrugorder” instance

    Sean Biefeld:
    ideally in my perfect world no object would exist that is invalid

    Sean Biefeld:
    im not saying there is no need for context

    Derick E. Bailey:
    it is context dependent – but implemented in a manner that is specifically suited to creating only valid entities. i love that idea.
    i think there’s a lot of great uses for that
    it always comes back to ‘what does this specific system need’

    Sean Biefeld:
    ya im trying not to think about it in a specific instance, but in ideal terms
    so i can work down to a specific instance with specific needs

    Derick E. Bailey:
    ya. the ideal world is always different than what we can actually do. i think we really do have the same general view on this…

    Derick E. Bailey:
    good distinction to make

    Derick E. Bailey:
    quite honestly, i’m probably very wrong in my opinions about what you can and can’t do, or should and shouldn’t do. maybe it’s not too much to ask for “if an object is created, it’s valid”.
    having people that are willing to challenge my assumptions forces me to re-think my own assumptions and see if there really is a better way

    Sean Biefeld:
    ya it all comes down to implementation and what is needed, and the capabilities of the language in use

  • Take a look at the Essense pattern (some would argue that it is a modified Memento pattern). This might allow you to do reactive validation in the Essense class (i.e. collect data one field at a time), and still allow proactive validation in the Entity itself. Just a thought…

  • Thanks for posting on this. This has been a difficult point for our team as well. As you have pointed out in one of your comments, Jimmy’s post really cleared stuff up. I wanted to point out that Jimmy’s post is just the beginning. Performing proper validation seems to point towards Command/Query Separation. Greg Young of CodeBetter has a highly informative InfoQ video on doing CQS—which he doesn’t relate directly to validation, but with Jimmy Bogard’s post, the two can be tied together nicely. In other words, watch the video and then read Jimmy’s post again. Also, take a look at my two most recent blog posts—I discuss the matter in more depth.

  • @jonothan

    I’m reading your posts now. thanks!