Most microservice problems are born long before RPC. They usually begin when the system is cut along the wrong seams.
In real design work, the chapter shows how bounded contexts, business capabilities, team topology, and data ownership shape decomposition far more than repository layout or implementation language.
In interviews and engineering discussions, it helps stress-test decomposition against distributed-monolith risk, expensive cross-service transactions, and orchestration-heavy coupling between teams.
Practical value of this chapter
Design in practice
Split systems by business capabilities, not by technical layers or repository boundaries.
Decision quality
Evaluate cuts using data ownership, team topology, and cross-service transaction frequency.
Interview articulation
Explain how the chosen cut reduces coupling and enables independent releases.
Failure framing
Stress-test decomposition against distributed-monolith risk and orchestration over-coupling.
Context
Why microservices and integration are needed
Decomposition sets responsibility boundaries, data ownership, and the future cost of integration.
Decomposition strategies determine where service boundaries sit, who owns data, and how quickly teams can ship change. The split itself does not make a system better; it becomes useful only when it lowers coupling, reduces cognitive load, and creates clear responsibility.
The hard part is not naming a service. The hard part is deciding which business capability, bounded context, team boundary, and data ownership rule should move together. A wrong cut gives you the network, on-call, and operational cost of microservices while keeping the coupling of the old monolith.
Why decomposition decides whether microservices help
Service architecture starts with boundaries, not protocols
A good boundary makes a team more autonomous, reduces failure blast radius, and lets the model evolve with fewer meetings. A bad boundary turns services into a distributed monolith: releases are shared, data is shared, and the system gained more network failure modes.
Fewer coordination points
the team can evolve its area without a queue of dependencies
Shared releases
services are physically separate but still have to ship together
Who owns the change
the main question before creating a new boundary
Decomposition drivers
Change speed
Different parts of the product change at different speeds, and one shared release train starts slowing teams down.
Cognitive load
A team should understand its area deeply without keeping the whole monolith in its head.
Different workload profiles
Catalog, payments, notifications, and reporting often need different scaling and resilience models.
Failure isolation
A failure in one area should trigger controlled degradation rather than taking down the whole user journey.
Decomposition strategy map
Decomposition strategy map
Boundary around an outcome, not a code layer
The same monolith can be cut by business capability, model boundary, team ownership, data ownership, or migration seams. Strong decisions combine several lenses.
Choose a lens
Start with what the business repeatedly needs to do
A service forms around a business capability: billing, order capture, catalog management, or identity verification.
Catalog
items and prices
Orders
checkout and status
Payments
charges and refunds
Profile
customer and access
Architecture outcome
When it fits
- different change speeds
- clear business owners
- weak shared transaction needs
Where it fails
- boundaries stay too broad
- several models remain inside
- no owning team
Review questions
- Can this area ship without neighboring teams?
- Is the service outcome clear to the business?
- Did we mix several domain languages together?
How to choose service boundaries
Business capability
Use when: There is a clear business outcome, owner, and independent change cadence.
Watch for: Do not cut too broadly: one area may still contain several different domain models.
Bounded context
Use when: Domain terms and rules start conflicting across teams.
Watch for: Do not turn DDD vocabulary into physical services before the organization is ready to operate them.
Team topology
Use when: The main pain is coordination, blocked releases, and unclear responsibility.
Watch for: Org structure alone should not become the only reason for a technical boundary.
Data ownership
Use when: Teams fight over schema changes, writes, or the pace of model evolution.
Watch for: Read copies need freshness rules, recovery paths, and compatibility support.
Book
Monolith to Microservices
Sam Newman's book explains safer ways to extract services from a running monolith.
Migration strategies from a monolith
Find the seam
Start with a user flow, integration, or domain operation where traffic can be intercepted safely.
Add a facade
Stabilize entry through an API gateway, adapter, or internal contract so old and new paths can coexist.
Move behavior
Extract logic in a small reversible step with metrics, tracing, and a clear fallback path.
Separate data
Move to an owned schema only after write ownership, synchronization, and rollback strategy are clear.
Decision review
Autonomy
Can the service be changed and released without coordinating with several neighboring teams?
Contract
Is it clear what the service promises to clients: data, errors, compatibility, and operational expectations?
Data
Is there a single write owner, or is a shared table still the real integration contract?
Failure behavior
What happens on timeout, neighbor outage, or partial failure in the business process?
Typical antipatterns
Splitting by technical layer: one service for API, one for database, one for business logic.
Creating tiny services that always release together and require constant synchronous coordination.
Leaving a shared database as the main contract between services and calling that decomposition.
Extracting services before CI/CD, observability, on-call ownership, and responsibility boundaries exist.
Practical checklist
Recommendations
- Prove the boundary inside a modular monolith first if team size and load do not yet justify a separate service.
- Record the architecture decision: why this boundary was chosen, which alternatives were rejected, and when to revisit it.
- Measure safe change speed, team autonomy, and failure blast radius instead of counting services.
- Extract the clearest reversible step with measurable payoff, not the most fashionable service.
Before extracting a service
- The service has an owner, a clear contract, and operational metrics.
- The boundary reflects a domain area, not package or repository structure.
- Neighbors get data through a contract, event, or read model instead of writing directly into another service's schema.
- Each extraction step has a rollback path, success criteria, and a plan to remove old code.
- The decision has been checked against distributed-monolith risk: shared database, synchronous call chains, and shared releases are not still the hidden center of the system.
References
Related chapters
- Monolith to Microservices - Practical strategies for gradually extracting services from a monolith.
- Learning Domain-Driven Design - How bounded contexts and domain language help choose boundaries.
- Interservice communication patterns - After decomposition, you need resilient ways for services to interact.
- Service Discovery - More services require managed discovery, health checks, and routing.
- Why microservices and integration are needed - The broader section context and where decomposition fits in the architecture map.