Menu
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!
812
You don't always need a service layer. Especially if your APIs are just simple CRUD operations, for example, with no real logic required or calculations. However, if you have an API which performs some logic before querying your repository then this should be in a separate service class.
A Service Layer defines an application's boundary [Cockburn PloP] and its set of available operations from the perspective of interfacing client layers. It encapsulates the application's business logic, controlling transactions and coor-dinating responses in the implementation of its operations.
In the domain facade approach a Service Layer is implemented as a set of thin facades over a Domain Model (116). The classes implementing the facades don't implement any business logic. Rather, the Domain Model (116) implements all of the business logic.
The service layer consists of a collection of Java classes that implement business logic (data retrieval, updates, deletions, and so on) through one or more high-level methods. In other words, the service layer controls the workflow.
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.
74
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
