Single Responsibility: o princípio que o mercado distorceu

O SRP não é sobre quantidade de tarefas, mas sobre quem exige a mudança. Robert C. Martin esclareceu em 2014 que um módulo deve responder a um único 'ator', um grupo de stakeholders com interesses alinhados, como contadores ou administradores de banco de dados. Misturar responsabilidades por motivos distintos (ex: regra de negócio + log + serialização na mesma classe) gera acoplamento, testes frágeis e manutenção cara. Em 2026, equipes estão deixando a interpretação subjetiva para trás: métricas como LCOM4 (ideal = 1) e CBO (quanto menor, melhor) permitem medir coesão e acoplamento objetivamente, transformando o SRP de princípio filosófico em critério técnico mensurável no CI/CD.

Essa medição já está sendo aplicada em arquiteturas modernas: em microsserviços, o 'monolito distribuído' surge quando se divide por camadas técnicas (ex: serviço de autenticação + serviço de notificação), violando o SRP; o certo é agrupar por domínio e ator, como 'serviço de faturamento', responsável por todas as mudanças exigidas pelo time financeiro. O mesmo vale para funções serverless e até documentação técnica: uma página de API deve ter uma única responsabilidade, descrever o contrato , , não misturar exemplo de uso, histórico de versões e política de rate limiting.

Ignorar o SRP não só prejudica a qualidade do código, mas amplifica riscos operacionais. Em Salesforce, por exemplo, 'personalização excessiva' e 'propriedade pouco clara entre equipes' (notícia CEVIU de 28/05) são sintomas de violações estruturais do SRP: módulos carregam lógica de múltiplos atores, então qualquer mudança no fluxo fiscal impacta integrações com CRM sem relação direta. No orçamento de IA, consolidar todos os gastos sob uma única rubrica de 'tokens consumidos' (notícia de 05/06) replica o erro, trata-se de uma 'classe Deus financeira', incapaz de priorizar investimentos por valor funcional real. O SRP, aplicado além do código, é uma ferramenta de governança: ele exige que cada unidade, técnica, organizacional ou orçamentária, tenha um motivo único para existir e evoluir.