Evolving an architecture: a problem solving-driven approach
architecting decision makingPublic workshops: Designing microservices: responsibilities, APIs and collaborations:
- Explore DDD, April 14-15, Denver Learn more
- DDD EU, June 2-3, Antwerp, Belgium Learn more
One handy heuristic for deciding on the granularity of services in a microservice architecture is a service should exist to solve a problem. That’s a great way to avoid creating an excessively fine-grained architecture. But recently, during my distributed data (a.k.a. service collaboration) patterns bootcamp’s weekly Q&A session, I was asked a different, thought provoking question:
We’ve undergone various layoffs and now we have more services than teams. Should we merge services?
In response to the question, I’ve written a new premium post Evolving an architecture: a problem solving-driven approach. It builds on the idea of Software Architecture as a Set of Architectural Design Decisions and describes a problem solving-driven framework for evolving an architecture that will help you answer this question and others like it.
Premium content now available for paid subscribers at 
