tl;dr The domain model is not well defined, it's probably designed with a db centric approach in mind.
The main purposes of DDD is to model in code the Business concepts and processes. I really doubt that your business concepts and processes are just bags of properties. But if they really are then yes, the Domain Model can be the same as the Persistence Model so you don't have to do any mapping.
The persistence model models how object state is stored. If you're not in the domain of databases, then domain and persistence model can't have the same purpose. One of the biggest mistakes I see with DDD is thinking about the domain model like it's still data driven. In DDD you don't have a concrete database. You have repositories. There are no one-to-many, many-to-many etc relations. There are no tables and no rows. There are just objects which try to represent the Domain as accurate as possible.
Simply put, the Domain cares about modeling business behavior while the Persistence cares about storing object state. I see two different responsibilites here.
About validation, you have 2 types: validation of input data format and then validation of other business rules according to what you change in an object state.
About the duplication, I think you are referring to the input format but like @EbenRoux said there are mechanism which can help with that . In asp.net mvc most of those validation rules have the js version included as well.
Let me tell you a little secret with services. While their interface can be defined in the Domain, their implementation can sit in the Persistence Layer, thus allowing them to work directly with the storage. And since the rest of the app uses the service in their abstract form (the interface), only the DI Container will know the dirty secret.
DDD is not about being cool, it's about designing an application according to the domain. I'll bet few develop an app for the sole purpose to be an UI for the db. The majority aims to provide a service with their software,to build a virtual product which solves a problem.
It makes sense that the design the app to be driven the problem you want solved and not by the technical tools you just happen to use.
How does this sound, you want a brick house but the constructor says:" Sorry but my saw only works with wood". Well, don't use a saw, use another tool wich can help cut a brick. The tools need to be adapted at the problem, not viceversa.