Software Architecture & Design Principles
Component Principles
- REP — the granule of reuse is the granule of release: a component is a unit you can version and release, not just a folder
- CCP — classes that change for the same reason, at the same time, belong in the same component (a packaging-level SRP)
- CRP — don't force clients to depend on classes they don't use just because they share a component with ones they do
- ADP — the component dependency graph must have no cycles
- SDP — depend in the direction of stability (toward components with low instability I)
- SAP — a component should be as abstract as it is stable; stable-and-concrete components become rigid
| Group | Principle | Tension |
|---|---|---|
| Cohesion | REP, CCP, CRP | REP/CCP push components larger (bundle what changes together); CRP pushes them smaller (don't bundle what unrelated clients don't need) |
| Coupling | ADP, SDP, SAP | Keep the dependency graph acyclic, pointed toward stability, and keep stable things abstract |
The three cohesion principles are in real tension, and every component design is a trade-off between them: maximize REP/CCP and you get large components that are easy to release together but drag in classes a given client doesn't need (hurting CRP); maximize CRP and you get many tiny, precisely-scoped components with release-coordination overhead. Early in a project, teams typically favor CCP (fewer components, less release ceremony); as reuse grows, the balance shifts toward CRP.
SDP formalizes "depend on things more stable than you": using the instability metric I = Ce/(Ca+Ce) from Coupling And Cohesion, every dependency arrow should point from a higher-I component to a lower-I one. SAP then says a component's abstractness should track its stability — a stable component (many depend on it) that is also concrete becomes rigid: hard to change, and everyone depending on it feels every change. The fix is to push abstractions (interfaces) into the stable component and concrete, volatile implementations into unstable ones that depend on it — which is exactly the shape Clean Architecture Boundaries describes at the whole-system scale.