Service layer design. Reason to put things into a

问题:

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?

回答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.

回答2:

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

This one is easy. The primary reason for moving code somewhere where you cannot see it is managing complexity. When you hide code behind some interface, you have to think only about that interface, not its implementation.

When the same reasoning comes to layers, you have one additional point: layers provide you with constraints on communications. You have public surface, which you have to manage, you have all internal code paths you implement, and you are allowed to access only next layer (via defined set of interfaces). This helps writing clearer code.

回答3:

If you are using the .net client, that is your repository pattern. DocumentStore and DocumentSession, or their interfaces IDocumentStore and IDocumentSession