Decomposition Heuristics

Decomposition heuristics are decision aids, not universal laws. Chapter 5 treats boundary design as a practical review exercise: teams should compare several pressures at once instead of searching for one magical splitting rule. The goal is not perfect certainty. It is better judgment before an expensive service boundary hardens into production reality.

Read the lessons in order. The first covers business capability as the usual starting heuristic. The second explains why change cadence can reveal artificial coupling. The third focuses on data ownership and why it matters without collapsing into service-per-table design. The fourth shows how risk, criticality, and scaling profile legitimately influence separation. The fifth closes with the heuristics that most often produce bad boundaries.

If a service discussion still sounds like “this table deserves an API” or “this screen deserves a backend,” Chapter 5 is the place to reset the decision frame.

In this section

• Decompose by Business Capability
  A practical lesson on why business capability is usually the strongest first heuristic for service decomposition and how to turn a capability idea into a reviewable boundary candidate.
• Decompose by Change Cadence
  A practical lesson on using divergent rates and reasons for change to identify components that may deserve separate boundaries.
• Decompose by Data Ownership
  A practical lesson on why authoritative data ownership often points toward strong service boundaries and why service-per-table is still the wrong conclusion.
• Decompose by Risk, Criticality, or Scale Profile
  A practical lesson on using reliability requirements, security sensitivity, and scaling pressure as legitimate inputs to service decomposition when business boundaries alone are not enough.
• Heuristics That Usually Produce Bad Boundaries
  A practical lesson on the decomposition shortcuts that most often fail, including service-per-CRUD, schema-first splitting, screen-based services, vague utility services, and org-chart-driven boundaries.