Ok this is gonna be brief. You're just decomposing to an absurd degree. That's simply it.
Look, forget the names and this and that. What benefit would you realize out of decomposing so much? Because that sounds like you took the convention and went with it blind.
You should decompose to microservices when a monolith becomes unbearable; either it assymetrically requires scaling, or the teams are like that and you can get away with it, technically.
You're introducing distributed computing problems into functionality that's begging you to be local, simple - just like momma used to make it. And the fact you use REST to communicate between them sounds like handling a long brittle chain made of paper-thin crystal.
Microservices have costs. Managing 40 of them would have me flinging grenades into the office by week 2.
https://microservices.io/post/antipatterns/2019/05/21/antipattern-more-the-merrier.html
Consider where the boundaries of your system are. Which services are related?
Create groups.
Which entities require independent scaling? Which entities must be updated transactionally and would be awkward to handle cross-service? Which have exotic requirements that would jeopardize the operations of another.
- Which entities require independent scaling?
- Which entities must be updated transactionally and would be awkward to handle cross-service? A 2-phase commit protocol isn't gonna cut it
- Which have exotic requirements that would jeopardize the operations(deployment, runtime performance/stability) of another?
Consider these and the borders of your each serviceof your services will start to appear.
If none of the above applies, domain-driven. Model your services to your domain entities - but this is the same trap since if you've reached this point you're cruising for a reason, rather than having an actual one.