Single Responsibility Principle

SRP: a module should have one reason to change—one axis of responsibility. Not "one method only," but grouping so domain rules, formatting, persistence, HTTP transport, and orchestration do not churn together. Violations show up as classes named `UserManagerServiceHelper` touched by every feature team.

Split by stakeholder or rate of change: pricing rules change for product; invoice PDF layout changes for design.

On interviews: identify two reasons to change in a god class and propose a seam.

Common pitfalls: splitting every function into its own file, confusing SRP with "never reuse," and micro-classes with no cohesion.

The trade-off is more types and wiring versus localized change impact.

Checklist:

• Name the reason to change for a module.
• Separate domain from IO and presentation.
• Avoid shotgun edits across unrelated concerns.