However, I'm unsure if this pairs well with microservices.
It pairs orthogonally. By that I mean that how you structure the internals of an application (whether it be a microservice or a monolith) has no bearing on how you structure your microservices to interact with each other.
You're asking us how to design your restaurant's kitchen by showing me what the dining area is going to look like. Sure, there's some expectation that if one is recently renovated and modern, so is the other, but that's a very loose expectation.
I like Clean Architecture, and I'd use it. I like microservices, and I'd generally favor using them. Both of those statement hinge on them individually being the appropriate for the use case at hand.
I could review the CA that you're looking at but it seems a tangential point to make based on the question being asked.
Our initial diagram for the services has around 9 services with 46 class libraries.
- I am unsure what you mean by "class libraries" here and how they're counted different from microservices.
- I would also advise caution with trying to immediately model the old application's entire feature set.
I make both of these statements for the same reason. When you're used to working with a monolith, it's very easy to mistakenly create what's comically known as a distributed monolith when moving to microservices.
A distributed monolith means that you're spreading the business logic across multiple deployed services without redesigning the interaction between components to actually promote microservices with truly independent lifecycles.
This isn't a guarantee. Maybe you really understand microservices and won't fall into this trap. But based on the question you asked, it seems you are still getting to grips with microservices and I'm going to make a judgment call here that you should tread very carefully.
My suggestion is to design one microservice at a time. For example, model all the customer behavior that you want, and create a service. Don't even think about the orders or the products yet. Finish your people service. When done, then (and only then) think about the product service. Don't think about the customers or the orders. And so on.
If there are multiple devs working here, all getting to grips with it, I would suggest pairing together on the first microservice so everyone's on the same page about this new way of working. Then, when at least the groundwork has been laid, other devs can look at other microservices in parallel.
However, avoid cross-contamination at all costs. If the topic of discussion is Clean Architecture in general, that's fine. But if a products dev is needing to talk to a people dev in order to get their code working, that's a very big red flag that you're creating a distributed monolith.
Is there any better ideas on how to do it?
See the previous section.
I have an internal drive that makes me want to squish them together.
Yeah that's your monolith habits trying to manifest, I reckon.
Should I instead replicate these libraries into a folder inside the API?
I don't understand your goal here but I worry about what you're trying to carry over from the old world into the new world. I advise you to revisit your design from the ground up instead of carrying something old along for the ride.
Is this overkill for a microservice?
When you ask about overkill, what you're focusing on is the effort of getting this set up. Generally speaking, a more productive question would be "how can I minimize this effort?"
You could set up an empty project template so that you don't have to design this base architecture over and over. For my current company I created a dotnet template that takes in a
-name parameter and spits out an entire solution (with empty projects, project references between them, and default packages that we use) using that service name in all the right places. It takes me about 30 seconds to generate the entire framework, and 15 of those are spent opening a command prompt.
It feels wrong to have so many projects in my solution.
Microservices are all about independent deployability. Generally, I will advocate for separate solutions for separate microservices but that's not for a technical reason.
What matters for microservices is the discretely deployable components. How you manage your source code (git repository wise, solution wise) is relatively irrelevant as to what makes a microservice a microservice.