Step 1 — What Patterns Really Solve (and When They Don’t)

Develop the ability to detect recurring design forces before reaching for a pattern.

What Is a Design Force?

A design force is a structural pressure acting on your system.

It usually comes from one of five sources:

Forces are not visible in the code structure alone.
They appear as friction in daily work.

How to Spot Recurring Design Forces

1. Look for Repeated Pain

Is the same complaint surfacing across sprints?

• “Tests break whenever we refactor.”

• “Adding a new option requires editing five files.”

• “We can’t change this without fear.”

Recurring pain signals a structural force, not an isolated defect.

If the issue appears in multiple modules, it is likely systemic.

2. Track Change Frequency

Open version history.

Ask:

• Which files change together?

• Which classes change most often?

• What kind of change is common—behavioral variation or structural modification?

If behavior varies frequently but the structure remains stable, the force is likely variation under stable abstraction → candidate for Strategy or polymorphism.

If object creation logic keeps changing, the force may be creation volatility → candidate for Factory patterns.

Change patterns reveal design forces.

3. Observe Conditional Explosion

If you see:

• Large if/else chains

• Switch statements growing every release

• Flags controlling behavior

You may be experiencing the force of behavioral variability.

The force is not “too many conditionals.”
The force is: “We need to support expanding variation without modifying stable code.”

That distinction matters.

4. Examine Test Friction

When tests are brittle, slow, or integration-heavy, ask:

• Are dependencies hard-coded?

• Are side effects difficult to isolate?

• Does state leak across boundaries?

The underlying force is usually need for isolation vs. direct coupling.

Dependency Injection, Ports & Adapters, or Facade may be relevant—but only if isolation is truly required.

5. Look for Ripple Effects

When a small change cascades across multiple files:

• Tight coupling is present.

• The force is independent evolution vs. shared structure.

Observer, Mediator, or event-driven patterns can address this—but they introduce indirection costs.

6. Identify Hidden Costs

Sometimes the force is not functional—it is cognitive.

Symptoms:

• Developers hesitate to modify code.

• Onboarding time is long.

• Debugging requires tribal knowledge.

The force may be comprehensibility vs. abstraction depth.

In this case, introducing more patterns may worsen the system.

When Patterns Do Not Help

Patterns are counterproductive when:

• The variability is hypothetical.

• The system is small and stable.

• The cost of indirection exceeds the benefit of flexibility.

• The team lacks shared understanding of the abstraction.

Over-application leads to:

• Accidental architecture

• Indirection without need

• Slower change, not faster

Patterns solve forces.
They do not create clarity by themselves.

Force Identification Framework

Before choosing a pattern, answer these questions:

1. What recurring tension are we experiencing?

2. How often does this tension appear?

3. What change is currently expensive?

4. What cost are we willing to introduce?

5. Is this force likely to persist?

If you cannot answer these precisely, do not introduce structural change.

Exercise

Choose one pain in your codebase:

• Test brittleness

• Tight coupling

• Slow feature change

• Duplication

• Complex branching

Now write one precise sentence:

“Because we need ______, we are experiencing ______.”

Examples:

• “Because we directly instantiate infrastructure dependencies, our tests are brittle and slow.”

• “Because business rules vary by region, adding new cases increases risk and modification scope.”

• “Because services call each other synchronously with shared state, small changes create ripple effects.”

This sentence defines the force.
From there, you evaluate patterns as trade-offs—not rules.

Closing Principle

Patterns are decision frameworks under pressure.

Mastery is not knowing many patterns.
It is recognizing when a force justifies their cost.

Architectural maturity begins with naming the force.