intermediate

Single Responsibility Principle

Группируйте behavior вокруг одной reason to change, чтобы domain rules, formatting, persistence, transport и orchestration не менялись вместе.

SRP: у модуля одна причина для изменения — одна ось ответственности. Не «один метод», а группировка так, чтобы domain rules, formatting, persistence, HTTP transport и orchestration не менялись вместе. Нарушения — `UserManagerServiceHelper`, к которому лезет каждая feature-команда.

Делите по stakeholder или частоте изменений: pricing — продукт; PDF счёта — дизайн.

На интервью: две причины изменить god class и предложенный шов.

Типовые ошибки: каждая функция в отдельном файле; SRP как «никогда не reuse»; micro-class без связности.

Компромисс — больше типов и wiring против локального impact изменений.

Чеклист:

Назовите причину изменения модуля.
Domain отдельно от IO и presentation.
Без shotgun edits по несвязанным concerns.