The idea to have a repo per endpoint (or better, per use-case) is fine. In a strongly typed language, you might also do this separation on the interface level, but potentially allow one repo to implement multiple interfaces when that makes sense. However, there's a different issue: if the application is very CRUD-y (as your seems to be), and the Service classes don't really do anything, then having them is just busywork without gain. In that case, rigorously following a controller-service-repo structure might hurt the design. You can add a service class in between later on if the need arises.
↧
Comment by Filip Milovanović on Split single repository/service into pieces in clean architecture?
↧