Service layer design. Reason to put things into a service layer

Question

I have a few design-related questions:

• should service layer interfaces reside in a domain layer? For example user service?
• what are the primary reasons to move a code part to a separate layer?
• should service layer reside at the same assembly as the application layer?

Thanks!

EDIT

I use a RavenDB and have quite skinny controller actions but two action are present as [NonAction] actions:

[NonAction]
public IEnumerable<Article> GetAllArticles() { 
    return this.session.Query<Article>()
        .Customize((x => x.WaitForNonStaleResults()))
        .AsQueryable()
        .OrderBy(d => d.CreatedOn);
}

[NonAction]
public IEnumerable<String> GetAllCategories() {
    return this.session.Query<Article>()
        .Select(x => x.Category)
        .Distinct().ToList()
        .OrderBy(x => x);
}

..As I don't use a repository pattern. Is it reasonable to put it inside a service?

Answer 1

should service layer interfaces reside in a domain layer? For example user service?

In DDD you must distinguish between 2 types of services : Domain services and Application services (not mentioning Infrastructure services).

• Domain services are located in the Domain layer and contain domain logic that doesn't belong in any entity or that spans across several entities.

• Application services are in the Application layer and define application-specific operations that coordinate calls to the Domain layer and possibly return a result. They may correspond to a use case or a subpart of a use case. Application services are directly called by the client while Domain services can't be.

Application service interfaces don't need to be in the Domain layer since they are not domain-specific but application-specific, and the domain doesn't use them. The Application layer references the Domain layer but not the other way around.

what are the primary reasons to move a code part to a separate layer?

The first benefits that come to mind are reusability (reuse your Domain elsewhere without carrying all your application-specific stuff along with it) and maintainability (group together things that change together).

See Separation of concerns, Single Responsibility Principle, Cohesion.

should service layer reside at the same assembly as the application layer?

In DDD, there is no Service Layer. The Application Layer is often equivalent to what other approaches call a Service Layer, though.

As I don't use a repository pattern. Is it reasonable to put it inside a service?

"By the book" DDD would require a Repository for this kind of operations. Even if you don't follow DDD that closely, I'm not a big fan of naming everything a "Service" when there are tons of more accurate names to give them : Data Access Objects, Data Gateways, etc. The key thing to realize here is that an object containing these methods should be placed in a low-level data specific layer (DAL, Infrastructure layer) because it deals with one persistent data store (Raven DB) explicitely.