Using MVVM and DDD in WPF application without having too many classes

DDD is most beneficial in handling comlex business problem. In real project, it should be used in more flexible way deponding on how complex the domain is. I would like to use a multiple-strategies approach to adopt it.

1. For most of case which mostly is about CRUD data with few change in data structure. I would only use:

   Presentation Layer : ViewModel
   Service Layer: ViewModel<->Domin object
   Domain Layer: Domain object same as Entity
   

2. For more complex Domain, where there are many important and reusable business logic on Domain object, then I would add core service (like your Domain.Application.Services.PersonService).

3. If there are also complex business logic needed for process data for easier mapping data between Presentation Layer and Domin Layer. I would add another model in Service Layer, similar as your Presentation.WpfClient.Model.PersonModel.

So basically the architecture you have righ now is ready for handling the case that your Person domain is very complex in your project. But I can't see it so far from your description.

To answer your questions:

1. You can remove the Presentation.WpfClient.Model.PersonModel in your MVVM models. It doesn't violate MVVM because in this case, your Domain Object is the Model, And you have Presentation.WpfClient.ViewModel.PersonViewModel as ViewModel.

2. You can merge Entity with Domain object if your Person domain doesn't have complex business logic.

This is way too many classes for a single concept.

Should I remove models from presentation layer (MVVM models) and use only models from domain layer (DDD models) ? Isn't it violation of MVVM at this point?

Yes, this is a preferable solution is many cases, especially if you don't use a communication mechanism like WCF. No violation here as MVVM doesn't impose a particular implementation of the model part.

Should I merge my entity (database) models with domain models? Isn't it violation of DDD?

Also, yes. Separating an entity into two (domain entity and "persistence" entity) usually leads to over-complication and anemic domain model. Here's more on this: Having the domain model separated from the persistence model.

Overall, I recommend you to look at this example. This looks like exactly what you need: a fully-fledged application written in WPF with the use of MVVM and DDD.