@Chris: Where different uses of the domain model require a variation in rules or where the rules are not stable then I somewhat agree that embebbing the rules may make make such undesireable. However for rules that are always applicable then these should exists in the domain model, your domain model should rich rather than weak. You could have both embedded and flexible rules, how they are injected is outside scope of this topic.

With regards to immediate validation, I disagree that you must surround every operation with exception catching, I’ll illustrate the technique and more importantly the concepts in a blog post forthcoming if you can hand on a few days.

Business code should not be inside the domain layer!

Now I do have some wiggle room on that and if you have simple validations such as Age must be > 0, or regular expression validators that make sure this string field for zip code really is a zip code, I can accept that in a domain layer.

I still think it’s bad practice to throw exceptions from properties in any situation though because then every single operation you ever do with your object you MUST surround it with try/catch, which isn’t really acceptable in my opinion which is why it makes sense to not combine domain objects + validation. But if you must atleast take advantage of enterprise library’s validation classes and do screening on Validation.Validate(object) instead of throwing random exceptions from setters.

Enumerable.Count extension method actually has a shortcut for ICollection interface - it just returns Count property without iterating the collection.

Thank you for submitting this cool story - Trackback from DotNetShoutout…

Sincerely, Reader