I think it should be a combination of both. The more levels of security, the better. For instance, the domain object could have constraints at the property level and the service could handle different types of exceptions.
In general it is a powerful idea to use "good design" as far as possible to mitigate the risk for security vulnerabilities. And, one of the most powerful design ideas from object orientation is obviously to "harden" the object itself as much as possible
to ensure it is not used in an insecure way by accident (which is the most common pitfall)
If we talk about entities á la Domain Driven Design (things that have a "thread of identity that transcends changes in attributes") there are two major ways design can help secure them.
First, teach your entities to speak "domainish" by using Domain Primitives (e g PhoneNumber, RoomNumber, or BookCount) as their parameters and return types. This relieves them of a lot of "low-level" validation (format, syntax etc) and stops a lot of simple mistakes and attacks.
Second, ensure that your entities are very well aware about the state they are in, and only allow the actions that should be allowed. For example, a plane may only taxi for takeoff if all loaded bags belong to a passenger that has also boarded the plane. Broken state management is the cause of a lot of subtle-to-find security problems.
Chapter 5 speaks about Domain Primitives. Chapter 4 contains a few tricks that are applicable for state management (e g design by contract). Chapter 6 and 7 are dedicated to different aspects of ensuring that an entity is created in a consistent state, and how to handle the complexity that arises from complicated states.
Yes, of course, and I accept that blame. In fact, i covet that blame. As does this tiny ad:
Sauce Labs - World's Largest Continuous Testing Cloud for Websites and Mobile Apps