Evolve backend-core to new major version #98
Description
When we started to give shape to this project, 4 years ago, the situation of what was available was a little bit different as it is today. So I'm thinking that we have to analyze what this set of libraries is offering and focus only on things that make it different compared to other things that are available in the open source world.
What I think that is valuable from this project is basically focusing on offering code re use for CRUD functionalities, that can be used in project with strict separation of concerns.
At the same time, it would be great to avoid reinventing the wheel, and re use things that are now available and widely adopted like Spring Data's CrudRepository and ease things so Spring Data can be used.
Why not just use Spring Data alone? .. well, basically because it enforces your services code to depend on data layer objects, and that is something that we prefer to avoid so each layer code is more separated (discussion of why we want that might be out of the scope of this ticket).
So this is what I'm proposing for the next big version of the libraries:
- Consider modifying the API of our mixin interfaces so they can be compatible with Spring Data's Crud Repository
- Avoid providing our own implementation of the crud repositories and use spring data's implementation
- Maintain the QuerySpec feature given that allows the definition of what and how we want to query from the data layer avoiding having to depend on data related object such as jpa annotations
- Make things super easier if we want to add specific dao methods outside the regular CRUD related dao operation, by using things like JPA Query Methods
- Seize the opportunity of introducing breaking changes like QuerySpec builder and other things that I don't remember right now
- Maintain strict separation of layers, so I don't need to carry data related transitive dependencies to the service or presentation layer, if I want to execute a new complex method to retrieve or persist data
- Transfer completely the conversion of persistent entities to the data implementation layer, so we avoid forcing the transitive dependency of persistent annotations to the other layers.
Let's discuss, because I might be missing something here.