Orthogonality

Two components are orthogonal when changing one has no effect on the other. An orthogonal system is composed of independent, self-contained parts with a single, well-defined responsibility each, so effects stay local.

Why it Matters

Orthogonality limits the blast radius of change: a modification or a bug is contained in one component instead of rippling through the system. It also raises productivity and reuse, because independent parts can be built, tested, and replaced on their own.

Signals

• A small change requiring edits across many unrelated components (a sign of non-orthogonality).
• Components that can be tested in isolation and swapped without touching others.
• Effects that stay local, with no surprising action at a distance.

Benefits

Localized change, easier testing and reuse, reduced risk, and less coupling to any one vendor, framework, or decision.

Risks

Pursued naively it can multiply indirection and layers; and it can pull against DRY when keeping parts independent tempts a little duplication. Over-decoupling adds its own complexity.

Tensions

Independence competes with DRY's drive to share: sometimes a small duplication preserves orthogonality better than a dependency would. The judgment is which coupling is worth its cost.

Examples

Swapping a storage backend without touching business logic because the two are orthogonal; a change to the logging format that touches only the logging component.