domain driven design - Doubts on application structure and communication directions -

i'm building cqs-style ddd-application. i'm having doubts on how 'components' work each other.

but first i'll give brief overview application's structure:

applicationservice    -> receives command objects    -> doesn't return results   -> acts on domain model   -> speaks aggregate repository domain modifications  queryservice   -> bypasses domain model; doesn't speak aggregate repositories   -> executes queries against database populate view   -> returns 'representation' objects  rest controller   -> receives http requests , binds 'body content' & request params command objects   -> delegates applicationservice post, put & delete requests   -> returns @ least http code   -> delegates queryservice requests  infrastructure  -> handles persistence db  -> contains scheduling operations  -> handles foreign domain events our domain model 'interested' in  'open host'   -> facade used other domains   -> facade delegates methods applicationservice domain modifications , queryservice data retrieval (bypassing repositories) 

questions:

1. is ok domaineventhandler corresponds repository , invokes methods on aggregate? or should correspond applicationservice?
2. queryservice returns 'representation' objects. these used ui , 'open host' facade return value. ok these objects reused return value facade? or should facade create own objects, results same?
3. applicationservice takes 'commands' input parameters. ok these commands used open host facade? or should facade accept primitive values , convert them commands when delegating applicationservice?
4. domaineventhandlers seem reside on 'infrastructure' layer. possible applicationservice or domain service subscribes domain event? or infrastructure responsibility?

all advice welcome!

is ok domaineventhandler corresponds repository , invokes methods on aggregate? or should correspond applicationservice?

in experience, handlers application services.

queryservice returns 'representation' objects. these used ui , 'open host' facade return value. ok these objects reused return value facade? or should facade create own objects, results same?

there lot of discussion here differences between open host service , application service. not clear me using open host service, or why exists.

applicationservice takes 'commands' input parameters. ok these commands used open host facade? or should facade accept primitive values , convert them commands when delegating applicationservice?

i pass in primitives on edges of application , convert them commands handled in application services

domaineventhandlers seem reside on 'infrastructure' layer. possible applicationservice or domain service subscribes domain event? or infrastructure responsibility?

i've considered handlers application services - things responsible orchestrating user case. use case might "when eventx received, send email , update database". in example, consider "the code sends email" , "the code saves database" infrastructure concerns, handler not be.

public class examplehandler : ihandle<exampleevent>  {     private irepository _repo;     private isendemails _emailer;      public examplehandler(repository repo, isendemails emailer)     {          .... set private fields..     }       public void when(exampleevent event)      {         _emailer.send(event.whatever);         _repo.save(something);     } } 

to honest, don't think in terms of layers - prefer hexagonal architecture style of thinking. in above example, event handlers have dependencies injected them , go business.