The Clean/Onion/Hexagonal architecture applies most clearly to microservices when viewing each microservice in isolation. Each MS has its own model and its own use cases and defines its own external interfaces/ports (both for supplying data and retrieving data). These interfaces can be implemented with an adapter that connects to another microservice, which may be as simple as providing an URL in the microservice's configuration. The internal architecture of a microservice is irrelevant to external users of that service.
With some contortions it is also possible to interpret a group of microservices through the Clean Architecture. Here the MSes together form the center model, whereas external gateways and routing infrastructure represent the outer layers. However, this viewpoint would be unusual and also breaks down when there is no clear separation between internal and external services: a service is usable as long as it can communicate over a network.
You mention that you will have several frontends. This can indeed mean that using an approach like the Clean/Onion/Hexagonal architecture is a good fit, because your business processes (the entities and models) will not be coupled to individual frontends. On the other hand, you should consider whether all these business processes form a common model, or whether they are separate bounded contexts in DDD-speak.
Your brief sketch of your requirements neither requires nor rules out microservices. Note that it can be an equally valid solution to put each service into a library and link those into a “monolithic” application. Microservices have clear benefits when
- you are willing to accept the difficulties of building a distributed system; and
- you either
- want to scale different parts of the system separately; or
- want to let separate teams develop and deploy their microservices independently.
Note that this is not an all-or-nothing approach, it can also make sense to build a mostly-monolithic application that just extracts individual components as separate services, for example a web app with a background job queue on a different server.
Difficulties of distributed systems not only include the administration of the system (administrating multiple servers, managing networks between them, possibly using Kubernetes) but also the tricky semantics for your application like distributed transactions (or the lack thereof), eventual consistency (aka. relaxing data consistency requirements), and overall system complexity from juggling parallel processes. Keeping processes stateless helps with the latter part. Sharing databases between microservices would make consistent and transactional data possible, but voids the separation benefits that microservices are typically used for.
Microservices have close to zero architectural advantages for taming complex systems. While MSes force you to keep separate components separate because there's a process level boundary between them, the same isolation is possible with libraries. However, the communication between microservices is effectively dynamically typed (unless you use a formal service description language that can generate the code for connectors). In contrast, static type checking between libraries can prevent some interface errors.
My opinion, given the little context available, is that a microservice-oriented solution is likely not a good fit for your organization. Your team may not have the experience to build distributed systems effectively, you likely do not need the technical scalability benefits, and with a single small team you definitively do not need the organizational benefits. In contrast, your interest at using the Clean Architecture as a guideline seems very sensible given your setting. It shines exactly for complex enterprise apps that need to integrate different systems. However, looking at domain driven design might also be very helpful to determine what should be part of the core model of your application, and when to spin off some aspects as a separate model/library/service.
