Fowler does not go that far.
Nor do I ;-)
I'm not advocating "loading up you're object with every application specific rules". All I'm saying is Domain Models should be more than just Data structures.
There are many other design patterns that make sense for various validation needs, including descrotors, proxies/delegation, adaptors, etc. I tend to use something akin to validation strategies, and/or state + visitors.
As you stated William, there are many different levels of validation requirements including actor input (application) validation, domain model (business) validation, transaction validation, system requirements, state (transition conditions), etc. There's not a one shoe fits all design pattern.
My original response was *only* addressing the statement about Domain Models as a simple Java Bean (only simple getters/setters) and all functionality in a Service Layer. Maybe I misread Derek's post, but it sounded like he was leaning on the ol' EJB Stateless patterns with DAOs / plain Data beans, and stateless functions.