Microservices aren't about how many layers each application has, or indeed about how they are implemented. They're much more about clear, separation of bounded context, and having multiple different processes that are each individually buildable, testable, deployable. When working in a larger org structure, you might find this allows you to organise your people to support the services in a way that the monolith starts to struggle with at certain scales.
Imagine a commerce site - Instead of one big application that tries to do everything, we have lots of apis that do 'product', 'shopping cart', 'orders', 'payments', 'returns' etc, and each one would maintain their own state
Microservice applications don't share databases, and instead communicate with each other over HTTP for sync or some sort of event technology (Kafka, Message Queues etc) for async.
Each one of those applications might be implemented in a complex way or have complex requirements, it's not what makes them a microservice.
So to your question - your implementation is less of a concern here. You can still have services/repositories if that's a pattern that you like, or CQRS patterns can also work nicely, it doesn't matter so much as the core principles of boundaries, communication and state management.
NB : Microservices therefore come with overhead. You need to be disciplined with contracts for APIs and Messages, you need to make sure you don't reinvent the wheel, teams need to collaborate with each other effectively. They work well at larger scales and certainly promote a deployment model that allows you to utilise as much compute as you can pay for, but there are times when they can slow you down due to dependency management.
