It’s been a while since developers and architects started using the term Microservices. There has been a big movement to migrate from old monolithic systems to a new remodeled system architecture based on the word microservices.
The problem I’ve been seeing is that the term Microservice implies that building microservices is just about splitting the monolithic into tiny, small services. Often, this understanding of the term leads teams to build a bunch of CRUD services, which is definitely what we want to avoid.
Sam Newman, the author of the book “Building Microservices”, states that we should design microservices based on the DDD concept of bounded contexts. In this approach, we could have a Customer entity in two separate microservices, sales and shipping, for example. Additionally, the idea is to have a set of classes that collaborate with each other in a single context, with high cohesion, so that if you need to change behavior, you change it in one microservice.
Stefan Tilkov believes that should decompose a monolithic application by carving it up and gives the example of an auth system as a good candidate to be a separate service.
I personally agree with both Newman and Tilkov. As I see it, a good approach when designing microservices is to think as if it were a product that serves one specific purpose. In this sense, one microservice solves one problem and offers one main feature. Nevertheless, we should always keep in mind that microservices might not be as small as the name suggests.
Denis Capeto 