Evolving an architecture: a problem solving-driven approach
Over the years, I’ve been asked repeatedly about the granularity of services in a microservice architecture. I used to say that a good rule of thumb is one service per team. My thinking was that this heuristic would solve ensure team autonomy. More recently, my thinking has evolved and the latest iteration of my answer is a service should exist to solve a problem. In other words, you should only define a new service if it solves a tangible problem (and doesn’t introduce any additional problems).
But recently, during my distributed data (a.k.a. service collaboration) patterns bootcamp’s weekly Q&A session, I was asked a different and rather thought provoking question:
We’ve undergone various layoffs and now we have more services than teams. Should we merge services?
In this article, I’m going to explore this question, expand on the idea that a service should exist to solve a problem, and describe a problem solving-driven approach to evolving an architecture. Let’s begin by looking at the concept of architecture as a set of design decisions.