Your mileage may very, but I will try to define based on how I have used them. Regardless of your persistence layer, I would define them for practical use as:
Domain Services - Services which exist to enforce the integrity of the domain and facilitate the insertion, creation, deletion, and retrieval of data from the domain. Additionally, domain services can orchestrate higher-level combinations of domain objects into viewmodels. Often, these are facades on top of repositories, working to hide some of the low-level implementation and to provide an interface more in line with the UL (ubiquitous language) to help manage expectations.
Application Services - Services which are specific to the implementation of a domain model or which have no dependency on the domain model. A classic example of this would be sending and email based upon a state change or action in the domain. This is usually a requirement of the application itself, and is likely not specified by the domain model. This can either be procedurally executed by an application service after a call to the domain service, or as an event raised from the domain service.
Like I said, this might not fit everyone's definitions, but this helps me to make sure that the correct concerns go into the correct place.
As to where is the better place to put the business logic - I actually think that is tricky. There is more than one type of business logic with this style of approach. If there is an application-specific logic requirement that cannot be defined within the domain, I would put it in the application service layer. Things that directly impact the domain, regardless of the application, I would put in the domain service layer.
The problem is really taking the time to identify what is a true "domain concern". For example, a user might not be able to post to a comment to some arbitrary application unless his email address is known. You could argue that this belongs in either layer. The key is really being consistent.
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
