Clean Architecture and Microservices

Question

Our team is in the planning stages of creating an enterprise solution for our back office. Our goal is to have one singular entry point for common tasks, such as changing an address or reprojecting a loan (we're an FI). We want several front-ends that are categorized by domain, but could pull from any number of these tasks. Does this imply a microservice architecture?

Being a relatively young and small team (three people at six years each), we have rather limited development resources to spend. However, we're very interested in implementing Uncle Bob's Clean Architecture principles across this enterprise solution.

We're in a .NET stack. How does Clean Architecture "play" with a microservice architecture? I see in the original diagram that the entities layer contains enterprise-wide business rules.

Does this mean that we can abstract out the above entities layer into its own microservice layer that has its own sort of Clean Architecture built in?

I'm having trouble abstracting the microservices out from the different contexts and domains that these several applications would use them, and how the .NET solution(s) could be structured. We're trying to map out an interconnected city, not just the floor plans for a house.

This question has helped in some regard; however, I'm looking for a little more detail. Hopefully a team of our size isn't biting off far more than we can chew.

Organizing Visual Studio solution for microservices?

Answer 1

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.