Migrating from monolith to a microservice architecture having a single API gateway to access multiple services i.e., cars, shoes, mobiles etc. I'm using NET 6, Docker, Docker-Compose, Ocelot for my project. I'd highly appreciate your feedbacks on my question below based on two scenarios.

Scenario 1

Number of solutions [ApiGateway.sln, Cars.sln, Shoes.sln, Mobiles.sln, ...]

Docker Container [ApiGateway, Cars, Shoes, Mobiles, ...]

Docker Sub Containers for Cars [Hyundai, Honda, ...]

Ocelot used for [ApiGateway, Cars, Shoes, Mobiles]

Sub-ApiGateways: used for all services. MasterAPIGateway will interact with the SubApiGateways of each services.

Details: For an instance, a call for getting all cars of Hyundai is made. So the MasterApiGateway calls the cars service. Now the car serivce uses its own ApiGateways configured using Ocelot to call the required project i.e., Hyundai.csproj methods.

Yes this can be simplied by removing the ocelot from Cars and converting projects into methods as in the 2nd picture below.

Scenario 2 Number of solutions [ApiGateway.sln, Services.sln]

Docker Container [ApiGateway, Services]

Docker Sub Containers for Services [Cars, Mobiles, Shoes, ...]

Ocelot used for [ApiGateway]

Details: This is too mainstream but what if each services cars is a big project in itself. Due to which I've tried to separate the services i.e., cars.service, mobile.services hosted in differnt ports as seen in the above image. Again what if services has a huge module i.e., cars.services.honda has over 1000 methods. Due to which I've created sub projects within Cars again hosted in different ports. However, I am trying to encapsulate these sub projects as a single service i.e., for cars only 5000 port will be used by the MasterApiGateway.

Please do suggest me best way to achieve this. Again each service and sub projects within each services is a huge project. So having all these in one solution is something I'm trying to avoid. Thank you for your feedbacks.

CodePudding user response：

this is a design problem and it is highly abstract and depends on business requirements so there is no absolute solution.
the scenario that you have car service and has api for each car may looks proper one BUT as you said each one of them is huge. THIS IS MY OPONION AND NOT A SOLUTION:

• if it is just HUGE in data dont bother your self its better go fore one service of car
• if all type of cars share same sort of functionality (methods , process..etc) then one service is ok.
• if each car type has its own methods and process (not just getting data) then you have complexity in business logic then go for services for each car or one main service of car with similar functionality which can be support by services specific to cars type which contains specific functionality to the car type. here the car service may be play role as aggregator service.
• if the car service become very very huge in code size in such a way that the maintenance require more than 5 colleagues (the number may be vary depend on organization size etc) then it should break in pieces.
• also look at ubiquitous language in Domain Driven Design. at least it helps your architecture to be more appropriate by hard communication with domain experts.

your problem is the very challenging part of microservices (true microservices) and its out of my experience (i am still studying the microservice architecture and always i find the huge mistakes on my previous works). so please discuss and study and just dont rely what i said.

these two articles are very very useful
decompose-by-subdomain
decompose-by-business-capability

CodePudding user response：

The first question you should ask yourself is why do you need microservices, and usually it's better to start with a modular monolith and then break out a service at a time when needed...

You really need to have a clear understanding of the reason why you do it and not just for the fun of creating a solution like this.

I agree what Rouzbeh says about domain driven design, start there! and find your true bounded contexts using the ubiquitous language as a guide.