Pattern Name: Microservices Decomposition Category: Application Architecture / Legacy Modernisation Complexity: High Stability: High: widely adopted, well-understood trade-offs
Monolithic applications: where all business logic, data access, and presentation code is bundled in a single deployable unit: are the natural starting point for most systems. Monoliths are simple to develop early, simple to deploy, and simple to test when small. As they grow, however, they accumulate complexity: deployments become risky (everything changes at once), teams step on each other’s work, scaling requires scaling the entire application rather than the bottleneck component, and technology choice is locked in for the life of the application.
Microservices decomposition is the pattern for moving from a monolith to a set of smaller, independently deployable services, each responsible for a bounded domain of functionality.
How do you decompose a large, tightly coupled monolithic application into smaller, independently deployable services that can be developed, scaled, and evolved independently: without creating a “distributed monolith” that has all the complexity of both approaches and the benefits of neither?
The failure mode of poorly executed decomposition is the distributed monolith: services that are too fine-grained, too tightly coupled through shared databases or synchronous call chains, or decomposed along technical rather than business lines. The result has the operational overhead of microservices (many deployments, network latency, distributed tracing) without the organisational or business benefits (independent deployment, team autonomy, targeted scaling).
Decompose the monolith into services aligned with bounded contexts: cohesive business domains with clear interfaces and minimal external dependencies. Each service owns its data, its business logic, and its deployment lifecycle.
Key principles of effective decomposition:
Bounded context alignment: Services should align with bounded contexts as defined in Domain-Driven Design: areas of the domain with a unified model, clear language, and natural encapsulation. Customer Management, Order Processing, and Inventory are likely candidates; “all the database queries” is not.
Database per service: Each service owns its own data store. Shared databases are the most common source of “distributed monolith” failure: they create hidden coupling between services that is impossible to evolve independently. The discipline of data isolation is hard but non-negotiable for true microservices.
API contracts: Services communicate via well-defined, versioned APIs: REST, GraphQL, or gRPC for synchronous calls; event schemas for asynchronous flows. API contracts are the boundary; implementation is the service’s own concern.
Incremental decomposition: Full decomposition from day one is rarely achievable or desirable. Use the Strangler Fig pattern to extract services incrementally, starting with the capabilities that have the most urgent need for independent evolution or scaling.
Operational maturity: Microservices multiply the number of deployed components significantly. Container orchestration (Kubernetes), service discovery, distributed tracing, centralized logging, and health monitoring are not optional: they are the operational foundation without which microservices become unmanageable.
Element types to use:
Diagram types: ArchiMate Application Layer diagram showing service topology and inter-service APIs; UML Component diagram for interface contract detail; UML Deployment diagram for container/orchestration topology; ArchiMate Implementation and Migration viewpoint for decomposition roadmap
MDG considerations: The «BoundedContext» and «Microservice» stereotypes are the governance instruments for microservices architecture. Tag each service with its owning team and business domain: without this, the architecture becomes un-governable at scale. Validation rules should enforce that every microservice has a named owner, a deployed technology stack, and at least one defined interface. A periodic model audit (queryable via EA GraphLink) should flag services missing this metadata.
Package structure: A Microservices Architecture package containing sub-packages per bounded context. Each bounded context package contains its services, data models, and interface contracts. A Platform & Infrastructure package documents the orchestration and observability infrastructure.
EA GraphLink and AI integration: Microservices architectures are complex reasoning environments: the interdependencies between services are critical for change impact analysis but hard to navigate manually. EA GraphLink enables AI-assisted dependency analysis: “What services does the Order Processing service depend on?”, “Which services would be affected by a schema change to the Customer entity?”, “Which microservices are owned by Team Alpha?”. For architects managing decomposition programs, having AI tools that can traverse the service dependency graph in the EA model: and surface risks or gaps in real time: is a significant productivity multiplier.
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.