Clean Architecture with Microservices

Question

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.

Answer 1

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.

Answer 2

I don't think you've given enough information to really give specific guidance here. At a very high level, the main thing that I would note to anyone breaking down a monolith is to avoid building a distributed monolith. That is, an architecture with all the disadvantages of a monolith and all the disadvantages of a distributed application.

The term 'microservices' has started to lose meaning for me and I'm quite sure it doesn't mean the same thing to everyone who uses the term. I'm hesitant to even try to say what I think it means. So, I'm going to weasel out of that and explain what I think you should do. Call it microservices, call it something else, I don't care.

The really important thing when breaking down a monolith is understanding how the various parts are dependent on each other. The reason for that is that your new design needs to be centered around autonomy over data. A big mistake that a lot of people make is to create two 'microservices' that share a database. It isn't completely pointless to make these independently deployable but if you think that you've decoupled the two services, think again. They are inherently bound by sharing the same data storage.* For example, if you have a service that creates orders, one that updates orders, and one that retrieves order data, they are inherently coupled by the fact that they all need to understand orders the same way. I'm not going to assert that it never makes sense to split these out, but I would argue that the starting point should be to assume that all of these operations are part of one 'system' or 'application'. If you change the data or database structure, all of these are likely to need to change in some way. There's just no getting around that. I'm sure you can find articles explaining complex strategies to avoid having to share a DB but for most teams, this will be both a waste of time and also a source of struggles that are similar, if not worse than what you are dealing with today.

The trick here, IMO, is to find the natural 'cracks' in your current monolith much like a stonecutter will split a stone where it 'wants' to split. Which parts of the system are 'clumped' together? Cleave between those clumps such that your APIs that represent the dependencies between these subsystems are simple, straightforward, and unlikely to change. A common strategy for this is related to the concept of Conway's Law. The idea being that you don't want the Accounts Payables project to have to update same systems that the Accounts Receivables project needs to modify. (That might be a bad example, my accounting knowledge is novice at best.)

The big advantage to doing this is that you get the big value win: it's easy to understand what a change means in these more focused subsystems. You also have clearly defined the dependencies between subsystems. And also importantly, each subsystem can evolve independently. If a team decides Python is a good choice for writing subsystem A and another team decides C# is a good choice for writing subsystem B, your decomposed architecture will not prevent that. Another way of saying that is if you are planning to build 9 systems that all look basically the same but just have a different 'subject' they operate on, you are probably missing the point. You are definitely missing the point if these 9 systems are going to use the same DB.

*People have pointed out to me that you can have different applications in the same DB using separate schemas. I agree if you have strict enforcement of isolation between schemas. The key is: as long as a system can move to a separate platform or DB without impact on any other subsystem, it should be fine.