Re: Application Service

I'll explain how my colleagues and I have organized things and let you compare/contrast that with what you've thinking. 

 We've built several large business applications using DDD (well, our take on DDD, anyways).  Each of these applications is a cohesive system, but exposes itself to the world in several ways: web UIs, desktop UIs, mobile sync APIs, partner integration services, administrative consoles, etc.
 

 We refer to each of those things as "clients" of the "application".  The application exposes a single facade for each client.  Thus far, our facades ave been web services (specifically, .NET web services).  Our facades expose only the API functions needed by that client.  The facades are very thing.  The facades speak in DTOs and request/response contracts.
 

 The facades delegate to application services right away.  They yse dependency injection and service location to instantiate the application service they need to delegate to for a particular operation exposed in the facade.
 

 The application services are many.  Each focuses on a single, or a very small number of related application functions.  The application services do what orchestration they need with their own logic when necessary, but ultimately are manipulating domain services, repositories, entities and agents.
 

 So we have hundreds of application services.  And they are exposed in various combinations through a half-dozen facades.
 

 I can't tell you that this is "text book correct."  But I can tell you it has served us fairly well.
 

 And we are trying some variations on this with dynamic application service "handlers" being looked up.