I’m reading your posts now. thanks!

http://jerry.cs.uiuc.edu/~plop/plop98/final_submissions/P10.pdf
http://www.codeproject.com/KB/architecture/essencepattern.aspx

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:
right
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

Thank you all very much for your comments on these questions… in combination with Jimmy’s post (http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/02/15/validation-in-a-ddd-world.aspx) 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 )

Just my $.02
:)

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.

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.

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.

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.