4.1 Design Principles That Survive Framework Changes
Frameworks change. Design pressure does not. A good design principle should help you reason even when the language, framework, or architecture trend is different.
The purpose of design is to make useful change cheaper and dangerous change more visible.
Core principles
Separation of concerns means different parts of the system should own different reasons to change.
Modularity means the system is divided into parts with meaningful boundaries.
Abstraction means callers depend on a simpler concept rather than every detail.
Information hiding means a module protects callers from internal decisions likely to change.
High cohesion means the things inside a module belong together.
Low coupling means a change in one module does not unnecessarily force changes elsewhere.
These are not aesthetic slogans. They are cost-control tools.
Design around change
A practical design question:
What is likely to change independently?
Examples:
- Payment providers may change independently from checkout policy.
- UI copy may change independently from validation logic.
- Authorization rules may change independently from route layout.
- Storage representation may change independently from business workflow.
When likely changes are trapped together, every future change becomes risky.
The over-design trap
Do not abstract everything immediately. Abstraction has cost: indirection, naming, testing, documentation, and debugging.
Good design finds a boundary where change pressure is real. Premature design invents boundaries because they look professional.