The problem with creating a dichotomy between "monolith" and "microservices" is that... well... it doesn't make any sense. You describe your "microservices" and I'll explain how it's really just a monolith.
"So let me get this straight, you have a Billing package and an Ordering package. How are these organized again?"
-> "We have a distributed system."
"So you you compile them together and deploy them horizontally across many machines? Like a distributed monolith?"
-> "No we use microservices. The two packages are compiled and deployed separately so there is no code dependencies between them."
"Okay. So if I understand this right, you develop each package separately but they both access the same database?"
-> "No no no no! Microservices are not just about code dependency management, they are also about data ownership. Each package is developed and deployed separately and also manages it own database."
"Ah, so you have two monoliths?"
-> "..."
You see the problem is that the above terms are too broad to describe anything meaningful about a system. And usually "monolith" is used to described the dependencies between code whereas "microservices" is used to describe dependencies about data. It turns out there is a lot of overlap.
Design and implement your systems according to your use-case and stop worrying about how to label them.
"So let me get this straight, you have a Billing package and an Ordering package. How are these organized again?"
-> "We have a distributed system."
"So you you compile them together and deploy them horizontally across many machines? Like a distributed monolith?"
-> "No we use microservices. The two packages are compiled and deployed separately so there is no code dependencies between them."
"Okay. So if I understand this right, you develop each package separately but they both access the same database?"
-> "No no no no! Microservices are not just about code dependency management, they are also about data ownership. Each package is developed and deployed separately and also manages it own database."
"Ah, so you have two monoliths?"
-> "..."
You see the problem is that the above terms are too broad to describe anything meaningful about a system. And usually "monolith" is used to described the dependencies between code whereas "microservices" is used to describe dependencies about data. It turns out there is a lot of overlap.
Design and implement your systems according to your use-case and stop worrying about how to label them.