According to whom? How do those microservices get anything done if they just live in their own isolated world where they can't depend on (call out to) any other microservice?

Would anyone care to explain the reasoning behind their down votes?

Connecting to a messaging queue or database count as a dependency?

Why not break a microservice into a series of microservices, its microservices all the way down.

Only if you cannot change one service without changing the other simultaneously. It's fine to have evolving messages on the queue but they have to be backwards compatible with any existing subscribers, because you cannot expect all subscribers to update at the same time. Unless you have a distributed monolith in a monorepo, but at least be honest about it.

Multiple services connecting to the same database has been considered a bad idea for a long time. I don't necessarily agree, but I have no experience in that department. It does mean more of your business logic lives in the database (rules, triggers, etc).

> Only if you cannot change one service without changing the other simultaneously.

Not true at all.

You're conflating the need for distributed transactions with the definition of microservices. That's not it.

> Multiple services connecting to the same database has been considered a bad idea for a long time.

Not the same thing at all. Microservices do have the database per service pattern, and even the database instance per service instance pattern, but shared database pattern is also something that exists in the real world. That's not what makes a microservice a microservice.

> If the microservice has dependencies on other services it is not a microservice.

You should read up on microservices because that's definitely not what they are not anything resembling one of their traits.