What Is a Design Force?
A design force is a structural pressure acting on your system.
It usually comes from one of five sources:
| Source |
Typical Force |
| Business |
Frequent change, feature variation |
| Technical |
Integration boundaries, performance constraints |
| Organizational |
Multiple teams touching the same code |
| Quality |
Testability, reliability, observability |
| Evolution |
Extensibility, backward compatibility |
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:
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:
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:
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:
Patterns solve forces.
They do not create clarity by themselves.
Force Identification Framework
Before choosing a pattern, answer these questions:
-
What recurring tension are we experiencing?
-
How often does this tension appear?
-
What change is currently expensive?
-
What cost are we willing to introduce?
-
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.