1

I'm building a REST API service based on Jersey & Hibernate which contains the following layers: Architecture

Each entity in the model has its own service in the service layer (interfaces). As described above, DTOs are passed to and from the service layer to the endpoints layer. The following is PolicySetService interface:

public interface PolicySetService extends BaseService<PolicySet, PolicySetDao> {
    String createPolicySet(String accountId, PolicySetDto policySet) throws PolicyException;
    void updatePolicySet(String accountId, String policySetId, PolicySetDto newPolicySet) throws PolicyException;
    PolicySetDto getPolicySetDto(String accountId, String policySetId) throws PolicyException;
    void deletePolicySet(String accountId, String policySetId) throws PolicyException;
}

Now lets take a look at EvaluationService interface:

public interface EvaluationService extends BaseService<Evaluation, EvaluationDao> {
    EvaluationDto createEvaluation(String accountId, String policySetId, EvaluationRequestData requestData) throws PolicyException;
}

I have been reading that its a best practice for one service (lets say EvaluationService) to call another (lets say PolicySetService) in order to get domain model entity for instance (Instead of calling directly to PolicySet Dao from EvaluationService) In my case, EvaluationService implementation should use PolicySetService to get PolicySet entity (not the DTO) to perform some business logic before the Evaluation Entity is being persisted. Currently, the PolicySetService returns DTO and i need to convert it to the real PolicySet entity in the EvaluationService. Note that the services should expose only DTOs to higher layers (but i need some how to expose the entity domain model inside the service layer, meaning between services) What is the best architecture to get this? Should i create another "internal" service interface for services to communicate with each other? Is there any better architecture for this?

user2318645
  • 31
  • 5
  • Don't create another set of DTOs unless you really have a good reason for that. For the communication between layers of your application, you can use your entities or the DTOs you already have. – cassiomolin May 15 '16 at 11:24
  • Hi @CássioMazzochiMolin Thanks for your response. I must use DTOs as the data i get from client and the data of the response is different than the domain model entities. – user2318645 May 15 '16 at 11:33
  • In this situation, designing a DTO for the response objects would be a smart choice. I already addressed a similar situation in this [answer](http://stackoverflow.com/a/36175349/1426227). It might be useful for you. – cassiomolin May 15 '16 at 11:40
  • @CássioMazzochiMolin i read the answer you provided. It's very nice and well detailed on why and how to use DTOs. But yet, it doesn't answer my question which is what is the best architecture for services to talk with each other but in Domain models entities and not in DTOs... Currently, my services interfaces get and return DTOs while when one service talk with another one (meaning when communicating inside the service layer), domain model entities are needed and not DTOs. – user2318645 May 15 '16 at 11:49

0 Answers0