Design Principles
Why boundaries matter more than cleverness
What this chapter is
This chapter is not a checklist. It is not a style guide. It is not a collection of slogans.
This chapter explains why design principles exist at all.
They were not invented by committees. They were discovered through failure.
The core truth
Design principles are damage control mechanisms.
They exist because:
- systems grow
- people change
- assumptions break
- time passes
Good design is not about elegance. It is about survivability.
Principles are not rules
Rules demand obedience. Principles demand judgment.
A principle does not say:
"Always do this."
It says:
"If you ignore this, something predictable will go wrong."
🧠 Mental Model Principles are warnings written in advance.
Separation of concerns: the foundation
When responsibilities mix:
- changes collide
- bugs hide
- reasoning slows
Separation is not about purity. It is about blast radius.
If something breaks, how much breaks with it?
🧠 Architect's Note A concern separated is a failure contained.
Boundaries create safety
A boundary is a line you agree not to cross casually.
Boundaries answer:
- what can change freely
- what must remain stable
- where assumptions stop
Without boundaries:
- everything depends on everything
- fear replaces confidence
- refactoring becomes dangerous
🧠 Perspective Most "tight coupling" is actually missing boundaries.
Single Responsibility, correctly understood
Single Responsibility does not mean:
"One function does one thing."
It means:
"One reason to change."
When code changes for multiple reasons:
- fixes interfere
- intent blurs
- history accumulates
🧠 Mental Model If a change request feels ambiguous, responsibility is unclear.
DRY, without superstition
"Don't Repeat Yourself" is often misapplied.
It does not mean:
- eliminate all duplication
- reuse aggressively
- abstract early
It means:
"A rule should have one authoritative definition."
Duplication of knowledge is the enemy. Duplication of code is sometimes the price of clarity.
⚠️ Common Drift Premature abstraction spreads mistakes faster.
Coupling vs cohesion
Cohesion:
- things that belong together
- shared purpose
- aligned change
Coupling:
- things that depend on each other
- shared assumptions
- forced coordination
High cohesion is good. High coupling is dangerous.
🧠 Architect's Note Aim to increase cohesion before reducing coupling.
Cleverness is a liability
Clever code:
- impresses briefly
- confuses later
- resists change
Clarity scales. Cleverness does not.
🧠 Perspective If code needs explanation, it is already fragile.
Design for change, not prediction
You cannot predict:
- future features
- future scale
- future teams
You can predict:
- change will happen
- assumptions will break
- pressure will arrive
Good design:
- localizes change
- limits impact
- preserves invariants
Abstractions must earn their place
An abstraction should:
- remove repetition of reasoning
- hide volatile details
- clarify intent
If it only:
- saves lines
- feels elegant
- looks reusable
…it is suspect.
🧠 Mental Model Abstractions should make misuse harder, not easier.
Design debt vs technical debt
Technical debt is often blamed. Design debt is more dangerous.
Design debt appears when:
- boundaries are skipped
- responsibilities blur
- shortcuts harden into structure
It compounds silently.
⚠️ Common Drift Most "legacy problems" began as reasonable shortcuts.
Minimal practice (still no code)
Problem: "A module handles validation, persistence, logging, and notification."
Ask:
- How many reasons can this change?
- Which changes should be independent?
- Where should boundaries exist?
If the answers overlap, redesign is needed.
What beginners gain here
- A sense of restraint
- Fewer "magic fixes"
- Cleaner mental models
What experienced developers recognize
- Why systems rot over time
- Why refactors feel dangerous
- Why clever designs age poorly
Principles were ignored.
What this chapter deliberately avoids
- Named patterns
- Framework opinions
- Methodology wars
- Dogma
Those are downstream.
Closing
Design principles are not about beauty. They are about longevity.
Boundaries protect clarity. Clarity protects systems. Systems that hold protect people.
Choose boring design. Boring design survives.