Domain Driven Design: Domain Service, Application Service

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.

EDIT:

As this seem to be a top result on Google and my answer below is not, please refer to this much better answer:

https://stackoverflow.com/a/1222488/1240557

OLD ANSWER (not so complete :))

In order to create good software, you have to know what that software is all about. You cannot create a banking software system unless you have a good understanding of what banking is all about, one must understand the domain of banking.

From: Domain Driven Design by Eric Evans.

This book does a pretty good job of describing DDD.

Register to download a summary of the book, or download the summary directly.