Microservices, but the business layer & data access as single binary?
So, I just got assigned in this project.
It has 3 microservices (user, payment, and thirdparty), but it only has controllers.
The business layer & the data access layer themselves are centralized in a single repository which will be compiled as a binary.
So, whenever a request gets into one of the microservice, it goes to the respective controllers and then goes to the business layer by invoking the interface on the compiled binary
My question is, is this architecture common?
I've worked on microservice projects before using golang. But it wasn't like this. It's usually just hexagonal architecture where all of the business & data access layer are located in their respective service and are connected to each other using interface. Each service communicates by using grpc.
The company itself has just started migrating from monolith to microservices. I'm worried that they still retained their MVC fullstack paradigm when migrating to microservice because their fullstack/monolith projects work like this (business & data access as a separate binary).
My biggest concern that it'd introduce a very tight coupling & would be harder to maintain as it gets bigger (and defeats the separation of concern of the domain). I'm wondering if this architectural design is common for C# microservices.
3 Replies
just out of curiosity, how are these binaries loaded?
they're built as a project reference/dependency of the resepective service
the code source itself is loaded in the solution along with the respective services
aaah ok so they're not dynamically loaded
anyway i wouldn't really claim having a microservice with all these layers to be weird in any way