At the Domain Driven Design User Group, we had an interesting discussion about microservices. It started with a question about when to use microservices.

Romain explained that where he works, architects decided to use microservices but that this decision wasn't the result of a Domain analysis, but more of a technological hype.

Before digging into the heart of microservices, someone asked what are microservices. Everyone heard of microservices, but in order to analyze the matter, we had to have a clear definition. We ended up with this one.

Microservices are applications that can be deployed independently

Once this was acknowledged, some examples from Netflix were given to illustrate that microservices could also be smaller parts of an application, and that an application could be composed of many microservices and that if a microservice is not available, then the rest of the application should continue to work, but without the functionality delivered by the unavailable microservice. In other words, applications composed of many microservices have to be fault tolerant.

Examples from Netflix included a recommendation engine, search bar, video streaming and such.

This led to another question: How big is a microservice? This seemed to be key for the discussion as many were convinced that this is where Domain Driven Design comes in. A microservice has to have a single responsibility which is covered by a specific domain. In the case of the recommendation engine, this service knows about the user and the catalog, but it does not aim to be responsible for the user and catalog database. For that, it can query something like a user service and a catalog service.

The boundary between microservices seems to be databases.

Different microservices cannot use the same database since a microservice has to be responsible for its own data.


Now that there was a clear definition of microservices and what they cover and how they interact with each other, we looked into the other advantages of microservices.

  • independently deployable
  • fault tolerant of other microservices
  • technology agnostic, each microservice having a clear interface
  • polyglot interfaces, since microservices can talk to each other through different mediums (HTTP, brokers, files ...)
  • potentially developed by different teams

These are nice points, but most of these advantages could also be reached with a modular monolith. Boundaries between a modular monolith and a microservice are slim, but we agreed that this style of clean architecture should be called a microservice.

So to answer Romain's problem, microservices could be a solution to his problem, but it would have been more reasonable to analyze the domain contexts before slicing it into microservices.

Thanks to all those who attended this user group as other discussions were also very constructive.