In DDD, when we need to create a Complex Entity we need to use a factory (what the DDD calls a Factory) of objects so we can reuse it throughout the project.
So you can create an abstract class containing methods that return consistent objects (in this case a Client object) with a single maintenance point.
Created the factory, you can use it in the Application layer. But if you want to make your code even more decoupled, you can create an interface with the signatures of your factory methods and map your factory to the other layers using IoC / DI.
Editing:
You can continue to use AutoMapper to perform mapping between Client and ClientViewModel, as the goal of AutoMapper is to transform / map objects, avoiding manual work.
However, to call methods of your Domain objects - such as the Pull () method - you can implement what the DDD calls Service. You create in the Domain layer an IClienteService interface and its respective ClientService that implements the methods to be consumed by the other layers (including I suggest removing the methods from the Client entity and creating a service delegating this serve / deposit responsibility to IContaService / AccountService You will have to deal with a series of situations like this that are not the responsibility of the Client entity, but rather Account.)
In your Presentation layer (from what I noticed in Asp.net MVC) you can receive this interface in your Controller's constructor via IoC / DI as I mentioned earlier.
Below are some considerations that I found pertinent to reinforce, because after reading your comment I was doubtful if it is already clear to you:
-
Your Domain entity should have no dependency on a
external framework. Then, remove [key] and other references to
external frameworks of your domain entity.
-
There are no problems in your Presentation layer knowing your objects
of Domain. It would have problems the inverse (Domain layer know the
Presentation layer).