Controller mapping for the Domain model

Question

We have the following situations in general, consider objects larger than the example.

Situation 1
We may have a request that has all Account parameters;
{"id":"1";"name":"test","some":"xxx".............} and the other fields.

Situation 2
We may have a request that has some Account parameters, for example in the case of an update;
{"id":"1";"name":"testUpdated"}

Situation 3
We may have a request that has some parameters from Account, as id plus has others as user together;
{"id":"1";"user":"xxx","service":"yyy"} in which case each piece of the request will become an object.

Example of Dominio

public class Account {    
    private Long id;
    private String name ;
    private String some ;    
}

I see some options;

1 - I can receive this Accountform in the controller and set its properties in the Account object and others if NO CONTROLLER;

+ atende as situações 1, 2 e 3 
+ separa a requisçao do objeto de dominio 
- polui o controller com codigo de conversao 
- controller fica cheio de setters.. se for uma classe maior como um objeto grande como um pedido fica bem confuso. 

controller(AccountForm from){
    Account account = new Account()
    account.setNome=form.getNome();
    account.setSome=form.getSome();
    Other outher = new Other();
    other.setSome(form.getSome());
}

2 - I can receive in the controller this Accountrequest have a method in itself as AccountRequest.getAccount() to return a mapped model, in which case the mapping is in the Request object itself.

+ separa a requisçao do objeto de dominio 
+ encapsula a conversao em um lugar de facil acesso. 
+ atende situacao1 situacao2 e situacao3; 
+ um objeto burro que so tem os parametros da requisçao tem alguma funcionalidade; 
- objeto de request tem duas responsabilidades representar a requisiçao e mapear para um model valido.

controller(AccountForm accountRequest){
   Account account = accountRequest.getAccount();
   Outher outher = accountRequest.getOther();
}

3 - I can receive direct account in the controller where it will be full of nulls.

+ elimino objeto de request 
+ alta simplicidade 
- atende apenas a situacao1 situacao2 , por que request pode ter informações sobre vários objetos... o que não funcionaria. 
- forte acoplamento.

controller(Account account){
    account.someMethod();
}

4 - Externalize this mapping of the request parameters to another request mapper object.

+ isola logica do mapeamento 
- complexidade ate para casos mais simples se usado como padrão para tudo por exemplo um find por id.
- mais uma classe para cada request;

In the case of responsive Api, 2 more classes are worse. speaking in terms of Sponse request....

request | mapper | model | mapper | response 
AccountRequest, AccountRequestMapper,Account,AccountResponseMapper,AccountResponse........ 

I’m doing Option 3 Hybrid plus testing for simple cases(find by id or updates).... with option 2 for example for more complex cases... seems ideal from what I’m seeing, I hope with your opinions it becomes clearer.. what could be better, however in the hybrid approach, the problem is that Oce does not have the famous "PADRAO" and has to think about how to do each case, and I see resistance in adopting something like this. The bad thing about PADRAO is that it generates architecture to make a find for example.

What you use /What would be ideal/ What becomes expressive and easy to maintain?