I'm fairly new at system architecting and I'm looking for some advice. My company is revamping its order management system. Currently is a monolith system that scales very poorly and is difficult for various teams to work on at the same time. I am reworking this to be a microservice architecture. My initial team will be creating the full system ourselves initially. And other teams will likely be maintaining them after the initial release. We'll be setting the initial code conventions and API architecture which the other teams will use to maintain it.

I've read a lot about the various different architectures out there. And I really like the Clean(Onion/Hex) architecture. Just where the dependencies point inward and the separation of concerns really makes the unit testing later on very easy. I've used this on various smaller projects already and my team is familiar with it. However, I'm unsure if this pairs well with microservices.

Our initial diagram for the services has around 9 services with 46 class libraries. 

An example service would look like this

    Users <- folder
    --Users.API
    --Users.Infrastructure 
    --Users.Contracts 
    --Users.UseCases
    --Users.Domain

I would really love some advice from some more experienced architects. Is this overkill for a microservice? Should I instead replicate these libraries into a folder inside the API? Is there any better ideas on how to do it? It feels wrong to have so many projects in my solution. I have an internal drive that makes me want to squish them together.

Edit: What I'm really asking here is if this architecture works well with microservices in general. Does my service structure make sense? The sheer amount of projects is larger then anything I've touched. I can scope per project but it's early in development and with things changing a lot I end up having to debug with all of them at the same time more often then not. So I bring them up with a docker compose profile.