1

I have read many articles about repository pattern and service layer but I have still some doubts in certain arguments:

  • Repository should return only aggregates and I should have repositories only for aggregates and not entities, for example Product and not ProductDetails. If I would to retrieve only some properties from Product for my UI, does I have to return complete Product from ProductRepository to ProductService and do filtering and mapping in service layer, with Automapper or any other mapping library, create a DTO or ViewModel and return to UI, or create directly in my DAL another model with only specific properties and create a method in repository that return that model?

  • Based on the answer of previous request, should I have 1:1 service-repository, referring to above example, ProductRepository should be injected in ProductService and do all actions on that aggregate with specific return data for my presentation layer?

  • Should it be better to use CQRS to divide my query and commands? Referring to previous requests, ProductService should be divided in ProductReadService that create raw sql and ProductWriteService that use my repository, or divide even my repository for writing and reading?

I hope I was clear. Thanks in advance.

1 Answer 1

1

ProductRepository should be injected in ProductService and do all actions on that aggregate with specific return data for my presentation layer.

It's not a strict rule. Services might or might not need more repositories. They orchestrate the indirection between boundaries. If boundaries are different aggregates, then good, but it can be also between aggregates and remote services/repositories. The possibilities are many. Some services don't even have a repository. But the most important is that not all the repositories have to be accessed through a service. Services' main reason to exist is not a repository to hide. It's orchestration. To ease access to very specialized jobs that are not totally related to the domain.

Should it be better to use CQRS to divide my query and commands? ... ProductService should be divided into ProductReadService which creates raw SQL and ProductWriteService which use my repository, or divide even my repository for writing and reading?

No as a default choice. I mean, CQRS is a great strategy but it can introduce unnecessary complexity. Designs should be sized accordingly to the problem they solve. If a solution is more complex than the problem it solves then it's going to be hard for you to sell the implementation.

This said if you find that your needs for both, querying and commands evolve at different paces and changes are driven by different forces (requirements) so that you find hard concealing both, then segregation can be the solution. Not because one does read and the other writes only, but because different services and repositories can work with different models. That's the point of CQRS. It doesn't segregate reading and writing only. It also does with models. Even with databases in some cases.

So start little. Keep it simple. Make it more sophisticated as the needs appear.

2
  • Thank you for your response. My final purpose is to return different DTOs from same repository, the creation should be done in service? For example complete aggregate Product has name , price ecc.. and i want only to show name, should I return all aggregate from repository and then create DTOs in service? Commented Dec 9, 2022 at 15:55
  • If by DTO you mean the model to be sent to a remote consumer or view, then no. That's better done from controllers. If you mean a big object which is composed of several aggregates and additional data required by some business process, then yes, but I wouldn't use the prefix DTO.
    – Laiv
    Commented Dec 10, 2022 at 7:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.