I would venture to say that you're likely working on a distributed monolith rather than microservices. There are many varying definitions but the two key ones a

I would venture to say that you're likely working on a distributed monolith rather than microservices. There are many varying definitions but the two key ones are that they have bounded-context/do-one-thing and that they are small built by a two-pizza-sized team or could be rewritten in two weeks. Another property is that they should be able to do what they do without tightly-depending on other services (e.g. calling them and awaiting a response to continue). I would expect to understand what a microservice does and how it does its thing simply by looking at the data/communication schemas, source code, and maybe a little upstream and downstream. Unless you are very curious about the details of different ways 'microservices' can be done wrong, there's little reason to stay and try to understand what's there. I could be wrong, like if the reason it doesn't make sense is lack of domain knowledge, in which case it may be worth staying and getting a view, but the environment doesn't sound very conducive for learning.