Fracture Planes
- Categories
- Architecture
- Sources
- Team Topologies
Natural seams along which a system can be split into parts owned by independent teams. Good fracture planes follow real boundaries such as business domain, regulatory scope, rate of change, risk, or performance isolation.
Why it Matters
Where you split a system determines coupling, ownership, and flow. Splitting along a genuine fracture plane yields loosely coupled parts a single team can own; splitting along an arbitrary line creates constant cross-team coordination.
Signals
- Good planes: a change stays within one part and one team; parts have distinct domains or change cadences.
- Bad planes: every feature touches several parts, and teams must coordinate for routine changes, a sign you split across a fracture plane rather than along it.
Benefits
Loosely coupled subsystems, clear single-team ownership, and faster independent flow of change.
Risks
Splitting along technical layers or org convenience rather than domain. Over-splitting into many parts, each adding a boundary and more cognitive load.
Tensions
The most natural domain boundary may not match the current team structure (see Conway's Law), so choosing it may require reshaping teams. More, smaller parts improve isolation but add interfaces to manage.
Examples
Splitting a system by business domain so each capability is independently ownable. Splitting by rate of change so a fast-moving part is not coupled to a slow, stable one.