dotnet core microservices actual development process for a newbie and clarification

Question

I am looking for some expert and right advice to begin work on a POC to make a decision on Microservices with DotNet Core development to deployment.

POC concept: Customer will choose some products, make order, apply discount, then payment. Customer can see his past orders.

I have already gone through a lot of articles on internet and videos for microservice arch. and development with dotnet core. Everywhere most of the time the tutorial or guidance take it to cloud.

I am looking for a help to give a start in local machine no cloud involvement. I have some queries before begin and seeking some expert advice on it:

Q1: Which is a right way to create services in dotnet core?

1. Do I need to create different solution (.sln) in dotnet core for each microservices "Product", "Order", "Discount", "Payment" i.e total 4 solution?
2. Or a single solution with 4 different API project will work?

Q4: Microservice communication: I'll create a async communication using RabbitMQ,

1. Do I need to create a separate class lib project /solution and then need to containerized it and deploy on docker?

Q3: Docker Deployment

1. Do I need to wrap all 4 microservices (each different .sln) in a single container?
2. or separate 4 containers and then deploy?

Q4: Will the containers communicate each other or microservices to follow async communication.

Q5: Is it possible to do Docker-Swarm Orchestration local machine.

My understanding and concepts:

1. microservices means each module or independent service running as a SRP.
2. microservice contains its own code, database and lib and act as SRP.
3. UI is interacting with each service, (we can implement API Gateway further based on our need)
4. microservices can communicate each other in async approach using any AMQP protocol based technique such as RabbitMQ, Kafka, Azure Service Bus
5. this AMQP based approach is treated as Event sourcing
6. for synchronous communication we can still use the sync pattern like REST, GraphQL, gRPC

Development tools:

1. Visual Studio 2019
2. DotNET Core
3. RabbitMQ for async communication, REST API for sync communication
4. Docker Desktop (I am running windows container in my case)
5. xUnit for testing
6. API management for services (Ocelot)

Buzz word Orchestration:

When more than 2 services are running (in my POC case) we need to manage them, so we shall move to big buzz word

1. Docker Swarm (will follow in my case)
2. K8
3. Service Fabric

Answer 1

Q1: Which is a right way to create services in dotnet core?

Do I need to create different solution (.sln) in dotnet core for each microservices "Product", "Order", "Discount", "Payment" i.e total 4 solution? Or a single solution with 4 different API project will work?

You can do both. Some companies use Mono repositories for micro-services. You can use Mono repositories for micro-services but you can also use separate repositories for parts of one Monolith application. Similar goes for solutions you can put all your micro-services in one solution but you can also place them in separate solutions. I would prefer to put each in separate solutions for practical reasons. This way you have the separated. This brings a lot of advantages. One of them is that you code will be physically separated and you will not have a chance to accidentally use code from one micro-service in another micro-service. Please read this answer here on Multiple micro services on one or multiple repositories. Lot of the points can be applied here as putting them in the same Solution usually would mean having them in one physical place together(which has disadvantages) similar as the case where you would put all of them in one repository. From my experience it is usually better to have separate Solutions per micro-service and have a separate repository.

Q4: Microservice communication: I'll create a async communication using RabbitMQ,

Do I need to create a separate class lib project /solution and then need to containerized it and deploy on docker?

No you would not containerize it. Micro-service communication usually happens from micro-service-A to micro-service-B. You would containerize micro-service-A and micro-service-B but not the RabbitMq library. Usually for cross-cutting concerns like code for RabbitMq interaction, DB access layer common classes, Testing infrastructure, Shared code for some Common things you would put in a separate Project/Solution. You can call it something like micro-service-common-library or micro-service-common-infrastructure or similar. You can build a nuget package(or multiple pacakges) from that library and add it as Reference in each of your micro-services. This way you will reuse common code and have all your cross-cutting concerns in one place.

Q3: Docker Deployment

Do I need to wrap all 4 microservices (each different .sln) in a single container? or separate 4 containers and then deploy?

Each micro-service should be in its own container. Think of this as if it where in Production. How would you scale the micro-services independently if they are all in one Container? You would not do that. I know you are talking about local Development env but containers are not heavy and we want to keep it close to Production setup to find bugs easier and work in similar setup as Production env.

Q4: Will the containers communicate each other or microservices to follow async communication.

Both ways. There are multiple ways how micro-services can communicate with each other. Please read the following answer here where I have explained the ways of communication :)

Q5: Is it possible to do Docker-Swarm Orchestration local machine.

I am not quite sure what you are asking but if the question is if you can use Docker-Swarm on your local machine? Then the answer is yes. You can also use docker-compose for this purpose.

1. microservices means each module or independent service running as a SRP.

Yes.

2. microservice contains its own code, database and lib and act as SRP.

Not quite, the part with libs is explained above :)

3. UI is interacting with each service, (we can implement API Gateway further based on our need)

Yes.

4. microservices can communicate each other in async approach using any AMQP protocol based technique such as RabbitMQ, Kafka, Azure Service Bus

Yes. Please have a look at the link about above where you have information about micro-service to micro-service communication.

5. this AMQP based approach is treated as Event sourcing

Not only Event sourcing. There are other Event patterns which are used in conjunction with micro-services. Here is a nice article from Martin Folwer where he explains: Event Notifications, Event carried state transfer and Event sourcing and CQRS.

6. for synchronous communication we can still use the sync pattern like REST, GraphQL, gRPC

Yes.

Please read this and this answers as it already covers a lot of the questions you are asking. It might help you ;)