Application service(s) as the implementor of use-cases

For a long time the role of application layer services has puzzled me. Usually they say app services must be thin, doing orchestration, transaction handling, logging, etc. But still it's a bit of an abstract description, pretty vague and I haven't found it a very constructive guidance on a day-to-day basis. It doesn't say anything about how many app services do we need for example. Just one big facade or many smaller? Then last week I stumbled across a video of Robert C. Martin (where he tells some very good stuff if you can put up with his sometimes infantile style of performance long enough) and got enlightened. Application layer services are the implementors of use-cases. Using it as the guiding principle, organising the app layer becomes more straightforward. A simple Use Case could be implemented by a single public method on the app service. I tend to group simple and related Use Cases in one app service, a public method for each. And I create a new app service class for each complex Use Case (requiring multiple interactions with the server, so multiple public methods).
So let's see it in an example with the evergreen Ordering application

//simple use cases for managing Customers
interface CustomerAppService {
   void registerCustomer(Customer customer);
   User findCustomer(Query query);
}
//simple use cases for retrieving information about Orders
interface OrderHistoryAppService {
   OrderHistory getLastXOrders(int num);
   Integer getNumberOfOrdersOf(Customer customer);
}
//one complex use case of managing the multi-step order process
interface OrderCompletitionAppService {
   Order initiateOrder(Customer customer, Item item);
   void processPayment(Order order);
   void confirmAndCompleteOrder(Order order);
}

Another complementary organisational principle could be creating app services per subdomain (if you have any, if you don't, it's always worth checking whether you could). And of course you may need app services overarching multiple subdomains.

So to say something very wise-sounding, application services capture what the application DOES, as opposed to the domain, that defines what it IS.