Microservices and service granularity

Question

I have never worked with microservices architecture before and there is something important that it is still not clear in what I am reading.

In a microservice architecture a service is a single endpoint or a single module with several endpoints?

Are the endpoints that are fine grained or the granularity is at a higher level? I thought at the beginning that the endpoints were fine grained and this is why there was the risk of making the API too chatty.

I am now finding articles that say that in microservices architecture a service is associated to "bounded context". It seems to me that a bounded context needs more than a single endpoint in an API.

Answer 1

Microservices Architecture (MSA), what does this mean? Well, first it means we are talking about architecture rather implementation, second, it means we are talking about something which is in micro level. In service orientation, a software service is a micro size if it is very narrowly functionalized. That means service with only one responsibility, or in another word, service will be small enough (businesswise) to receive a request and response with no server side state management. More gently our micro-service needs to be bounded context. Let me make it clear with a simple example, consider developing a payment service, traditionally this service will provide credit payment, debt payment, pay-pal, web-money and etc. while in MSA each of which will be an independent service. You can read more in my code-project articles:

Dive-into-Microservices-Architecture-Part-I

Dive-into-Microservices-Architecture-Part-II

Dive-into-Microservices-Architecture-Part-III

Answer 2

In a microservice architecture a service is a single endpoint or a single module with several endpoints?

Conceptually, microservices are just services, which is to say they are just objects processing messages. Messages come in, the service decides whether or not to update its own in memory black box, messages go out.

The integration layer that you put in front of a microservice might have several different "endpoints" to help you pass in new messages to be processed.

Are the endpoints that are fine grained or the granularity is at a higher level?

Either way - there is fundamentally nothing wrong with having a single endpoint that sends a burst of messages to the service.

I am now finding articles that say that in microservices architecture a service is associated to "bounded context".

Yes, me too. I haven't seen any that demonstrate that they mean "Bounded Context" in the sense that Eric Evans originally described in the blue book.

Answer 3

It depends on how granular you want your architecture to be. Theoretically, for maximum granularity and according to Single Responsibility Principle you should make a microservice for each Aggregate, in each bounded context. This means that every command should have an endpoint (I assume that each endpoint is reached at a single URI, i.e. https://server/place/order).

If you use a CQRS architecture then for the read/query side, you could also have a microservice for each read model; in this way you can scale independently each read model (using DB replication or entire microservice instance replication).

Answer 4

I would suggest checking the following two books - Building Microservices and Production-Ready Microservices. Great read for everyone who wants to start journey with microservices.