# Shearing Layers

**In short:** Shearing Layers means grouping parts of a system that change at similar rates and keeping them apart from faster or slower parts. The boundaries between layers help lasting abstractions emerge.

## Explanation

Shearing Layers is a design principle. It says to organize a system so that artifacts (code, data, schemas and other things you build and maintain) that change at a similar rate sit together.

The idea draws on a model of buildings with six layers: Site, Structure, Skin, Services, Space Plan, and Stuff. Brand distilled these six from layers that Duffy proposed.

**Fault lines.** Where change rates differ, the layers act like fault lines. These boundaries help enduring abstractions emerge. An abstraction is a simplified concept that stays useful over time.

**Fast things move into data.** Things that change most quickly migrate into the data. The system then holds them as values that can be edited, not as code that must be rebuilt.

**Slow things resist change.** Widely deployed elements are hard to alter. Enterprise database schemas are an example. Reorganizing a schema in a large enterprise database is expensive and slow.

**Two forces in tension.** Adaptability (how easily a system changes) and stability (how well it stays the same) pull against each other all the time. Grouping by change rate is one way to balance them.

## Example

An online shop has prices and promotions that change daily. Its checkout rules change a few times a year. Its customer database layout rarely changes, because many systems depend on it.

The team keeps prices and promotions as data that staff can edit. Checkout rules live in their own part of the code. The database layout stays untouched. Each group changes at its own pace without forcing changes in the others.

## Trade-offs

Moving fast-changing things into data gives adaptability. Leaving widely deployed elements alone gives stability. You cannot maximize both everywhere. You must judge how fast each part really changes and draw the boundaries there. Parts that are widely deployed, such as large enterprise database schemas, are costly to reorganize, so a wrong boundary there is expensive to fix.



## Checks

- The document states which parts of the system change at similar rates and groups them together.
- Elements that change most quickly are kept in data, not hard-wired into code.
- Widely deployed, hard-to-change elements, such as enterprise database schemas, are identified, with the cost of changing them noted.
- The balance between adaptability and stability is addressed explicitly where layers are chosen.

## Related

- [Design for Change](https://arc.fuet.ch/concepts/principles/design-for-change.md)
- [Adaptability](https://arc.fuet.ch/concepts/quality-attributes/adaptability.md)
- [Modifiability](https://arc.fuet.ch/concepts/quality-attributes/modifiability.md)
- [Separation of Concerns](https://arc.fuet.ch/concepts/principles/separation-of-concerns.md)
- [Layers Pattern](https://arc.fuet.ch/concepts/styles-patterns/layers-pattern.md)
- [Big Ball of Mud](https://arc.fuet.ch/concepts/fundamentals/big-ball-of-mud.md)
- [Architecture Decay](https://arc.fuet.ch/concepts/fundamentals/architecture-decay.md)
- [Architectural Force](https://arc.fuet.ch/concepts/forces-decisions/architectural-forces.md)

## Sources

- [Big Ball of Mud](https://www.laputan.org/mud/mud.html) — laputan.org, accessed 2026-11-09