Domain services vs Application services

Question

What is main difference between domain and application services? (I'm using NHibernate)

Which layer would be better for business logic? What's best practice?

-S# Architecture uses application services as "coordination layer" but don't bother to explain why it's not domain service where should be business logic.

Answer 1

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.

Answer 2

I think the post that @Karsten quotes in his comment is more authentic than the most upvoted answer that @joseph.ferris posted here.

Domain services are for "a significant process or transformation in the domain that is not a natural responsibility of an ENTITY or VALUE OBJECT" (Eric Evans Domain-Driven Design).

Application services are just some sort of a facade or an API for your application (or other external consumers), they typically correspond to a use case of the application and are a set of application operations required by the interfacing client layers. They won't contain business logic, or anything that the domain experts might come one day and ask to change. They might contain transaction management (unit of work), application validations (validate state of objects retrieved from database / input saved to database), security validations and cross cutting concerns such as logging, caching etc. and orchestrate domain objects into viewmodels. They're especially useful when you have multiple clients (e.g. Web API and MVC) and the use cases responses involve multiple transactional resources (See "Service layer" section in Patterns of Enterprise Application Architecture by Martin Fowler).

Application services can contain a call to the repository to obtain a domain object filled with data, then they might call some method on the domain object or a domain service and call the repository again to persist the modified domain object. They're typically 'broader' from a domain service because they contain an entire use case.