What design pattern would you choose for a typical web service?

Question

Database

Already the third project for me is a web service with a database.
In the general case, the task is formulated quite simply:
- storing data in a database
- CRUD via REST
- more complex business logic also via REST
To solve the problem, I usually use my own version, similar to MVC:
the model is usually an ORM along with validators, written indexes uniqueness, etc.
helpers - more complex logic that uses a model in which CRUD or basic operations can be written (for example, guaranteed retrieval of a record from a database)
"services" - classes that use helpers (and sometimes a model) in which the real business logic
of the presentation is hidden - methods, processing incoming HTTP requests, calling "services", formatting the result
My doubts and problems:
1. The model is strongly tied to the database (be it mongoDB or MS SQL), and in most cases its logic (and indeed the logic of the entire system) somehow implies and takes into account the specifics of the database.
2. The levels I described above are essentially a model. There is no controller and views in their classic form. Are they really necessary in this case?
3. Unit testing is very difficult, if at all possible and makes sense. Instead, I use behavioral testing with typical business logic scenarios (filling the database with the necessary data, execution, evaluation of the result).
Questions:
Which design alternative would you choose? Are there any theoretical calculations on this issue?
Should abstraction be strengthened to make the code more "canonical" and easier to test?

Answer 1

I will answer myself.
Preliminary scrutiny of the Internet and questions to colleagues led to the following thoughts:
For such systems, the "repository" and "query object" design patterns are suitable.
Query object can build database queries, repository can work with collections (and uses query object to build request bodies).
The layer of logic that will rely on them is the same business logic of the application. In my case, an interesting effect turned out - a lot of logic went to the top level (which is quite expected, because the repositories are responsible for rather primitive things), and the BL began to resemble long scripts. Some repeated pieces appeared in the scripts, which (again, from the reasoned position of colleagues) were packed into blocks at the same level.