Conway's Law in Practice
Conway's Law states that organisations design systems that mirror their communication structures. If your teams are organised by layer (frontend, backend, database), you will build layered systems. If your teams are organised by business capability, you will build services aligned with business domains.
You cannot build microservices without restructuring teams. If you keep the same team structure and try to adopt microservices, you will build a distributed monolith.
The Domain Boundary Test
A good microservice boundary means:
- The service can be developed, deployed, and scaled independently.
- The service owns its data exclusively. No shared databases.
- The service handles a coherent business capability from end to end.
- Changes inside the service rarely require changes in other services.
Data ownership is equally critical. Shared databases are the most common cause of tight coupling. When two services share a database, they share a deployment boundary. A schema change in one service breaks the other. The solution is database per service.
The Distributed Monolith Trap
The worst outcome is a distributed monolith: services that cannot be deployed independently because they are tightly coupled. Every change requires coordinated deployment across multiple services. The operational overhead of microservices without the benefit of independent deployability.
Our Recommendation
Start with a modular monolith. Extract services only when a module clearly meets the domain boundary test. Team structure should drive service boundaries, not the other way around.
Start with 2-3 services, not 20. Prove the model, establish the practices, and then expand. The organisations that succeed with microservices are those that grow into them gradually, not those that adopt them wholesale from day one.