Am I using service layer correctly?

Question

Hi, I have been reading up on DDD and I think I may be using services wrong or at least in a not so ideal way. My service classes tend to have quite a few instance variables containing repository references and they seem to do a lot of work (i.e have a lot of methods).

Is it advisable to create more focused services? Like one method per service that performs some specific logic? Also, should service classes store instance variables to other entities? I read something about services being stateless, I'm not sure if I am breaking that rule by having those instance variables.

Thanks!

Answer 1

I would recommend reading up on dependency injection, inversion of control and the like.

Here's Fowler's article: http://martinfowler.com/articles/injection.html, though I always found him to be a bit over the top. I would try walking through a tutorial that represents using a DI/IoC container.

Answer 2

My service classes tend to have quite a few instance variables...

This is not necessarily a code-smell. If your service requires many dependencies to complete its work, then this is simply a fact.

...they seem to do a lot of work (i.e have a lot of methods).

Is it advisable to create more focused services?

As a general rule, the more granular you can make your service-interfaces (i.e. the fewer methods), the better (ever had to trawl through an interface with fifty methods on it looking for the one that you want to call?). But unless you are releasing as a public API, the granularity of your service-interfaces can be refined as you go along. Often, when starting a project, I will begin with just one service, and split it out over time. If you are the consumer of these services, then when you start to feel the pain of an interface getting to large, you will know it is time to break it up. Of course, if this is a public API, then you will have to do a lot more up-front design.

Also, should service classes store instance variables to other entities? I read something about services being stateless, I'm not sure if I am breaking that rule by having those instance variables.

Storing dependencies as instance variables does not necessarily imply that your service is not stateless, as long as the instance variables are also stateless. To be considered stateless, method calls on a service must not in any way depend on previous methods having being called. You should be able to load a single instance of service, and have it shared for your application (i.e. an instance of a stateless service should not be specific to a particular user's session). In other words, your service should not maintain any state between method calls. Storing a stateless repository dependency as a variable on a service instance does not violate this requirement.

The reason stateless services is a desirable goal, is having no state greatly reduces the possibility of bugs. It simplifies the testing of a service method by restricting the test-cases to varying the parameters passed in, rather than having to worry about the previous state of the service. It can also offer performance benefits.