Evolving an architecture: a problem solving-driven approach
architecting decision makingPublic workshops:
- Enabling DevOps and Team Topologies Through Architecture: Architecting for Fast Flow JNation, May - Coimbra, Portugal Learn more
- Designing microservices: responsibilities, APIs and collaborations DDD EU, June 2-3, Antwerp, Belgium Learn more
Contact me for information about consulting and training at your company.
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 
