Monolith vs. Microservices
Monolith and microservices are two fundamental approaches to software architecture. A monolith deploys all functionality as a single unit — one codebase, one build, one deployment. Microservices decompose functionality into independently deployable services — each with its own codebase, build pipeline, and runtime. The choice between them is not binary; many systems exist on a spectrum including modular monoliths and service-oriented architectures.
Why It Matters
The monolith-to-microservices debate is one of the most consequential architectural decisions a team can make, and one of the most frequently made without adequate structural data. Teams decompose monoliths based on organizational structure, feature boundaries, or intuition — without verifying that the dependency graph supports the proposed decomposition.
A microservice extracted without clean dependency boundaries carries its coupling with it, becoming a distributed monolith — the worst of both architectures: the operational complexity of distributed systems with the change coupling of a monolith.
Structural analysis reveals whether proposed service boundaries are achievable by measuring the cross-boundary dependency count. If the proposed boundary has 50 cross-boundary dependencies, the decomposition will be difficult and risky. If it has 3, the boundary is clean.
The same analysis applies in reverse — teams considering consolidating microservices into a modular monolith need to understand the coupling implications of co-locating previously independent services.
How It Works
Structural analysis supports the monolith/microservices decision by providing evidence about boundary quality.
Zone detection identifies natural clusters in the dependency graph — groups of files that are tightly connected internally but loosely connected to other groups. These clusters represent potential service boundaries.
Boundary analysis counts the dependencies that cross each potential boundary. A clean boundary has few cross-boundary dependencies. A polluted boundary has many, indicating that the proposed service split would create a distributed monolith.
Circular dependency analysis at the zone level identifies clusters that depend on each other mutually, indicating that they cannot be independently deployed without resolving the cycle.
Blast radius analysis for files near boundaries determines whether changes in one proposed service would frequently cascade into the other, undermining the independence that microservices are supposed to provide.
How Axiom Refract Addresses This
- Axiom Refract's zone detection automatically identifies natural architectural clusters that represent potential service boundaries
- Cross-zone dependency analysis reveals boundary quality — how many dependencies cross each zone boundary
- The Untangler module identifies circular dependencies between zones that would prevent clean service decomposition