Princípio da responsabilidade única também é sobre pessoas

O livro Arquitetura Limpa de Uncle Bob traz insights interessantes a respeito de princípios de design, especificamente sobre SOLID. Uma dessas visões é que podemos enxergar os princípios tanto para refletir um bom design de classes tanto quanto para componentes , módulos e até aplicações.

No breve resumo sobre o princípio de responsabilidade única(SRP), temos a seguinte explicação:

Um colorário ativo da lei de Conway: a melhor estrutura para um sistema de software deve ser altamente influenciada pela estrutural social da organização que o utiliza, de modo que cada módulo de software tenha uma, e apenas uma, razão para mudar.

Neste resumo ele fez um paralelo entre SRP e a Lei de Conway. Para entender essa analogia podemos ir até a sua definição:

Organizações que desenvolvem sistemas de software tendem a produzir sistemas que são cópias das estruturas de comunicação dessas organizações.

Isso significa dizer que a forma pela qual times são estruturados reflete diretamente no software. Por exemplo, se tivéssemos equipes distintas para cuidarem de tecnologias específicas de um mesmo projeto de maneira separada teríamos uma visão semelhante ao desenho abaixo:

Assim, um mesmo produto seria construído a partir de diversas perspectivas diferentes. Visões de backend, UX/UI, Mobile e Database. Isso implicaria em menos visão de produto e mais uma ótica centrada em tecnologias nas soluções.

"…quando equipes distintas trabalham em suas especialidades o sistema segue a forma de comunicação das equipes, ou seja, separado ou particionado por especialidade." (Freitas, 2017)

Foram desses insights que surgiram ideias como equipes multidisciplinares onde times são formados com membros de especialidades diferentes. Atualmente, este modelo é amplamente utilizado no mercado.

"…as equipes multidisciplinares produzem sistemas individuais completos, contemplando todos os aspectos do software, inclusive a interação com outros sistemas." (Freitas, 2017)

Como complemento, Fowler e Lewis fomentam o que chamam de "mentalidade de produto", onde o time consegue com esse formato focar mais em atender e evoluir requisitos de negócio.

Mas então, onde entra o princípio de responsabilidade única aqui ? E se tivéssemos times multidisciplinares, resolveríamos essa questão ?

Pense nesse exemplo abaixo:

Vamos supor que temos dois times separados que trabalham respectivamente com vendas e compras de produtos. Esses times usam uma aplicação que os mesmos podem criar algum código para atender as suas necessidades. Essa aplicação possui um client para uma API de produtos.

A nível de código, poderíamos pensar no seguinte cenário:

Os times usam atualmente a classe ServiceProduct para buscar na API produtos. Existe um método privado calculatePrice(Product) que possibilita o cálculo base do produto e atualmente é usado pelo método listProducts() do qual os dois times chamam. Vale ressaltar que regras de cálculo hoje estão todas contidas nessa aplicação.

Um belo dia o método calculatePrice(Product) precisa de mudanças tendo em vista que a regra de cálculo para o time de vendas mudou. Porém, este método tem a lógica pela qual o time de compras utiliza.

Existem N soluções para esse problema mas o objetivo aqui é outro. Uma pergunta que pode direcionar a reflexão:

Existe aqui a violação do princípio da responsabilidade única ?

É possível dizer que sim. Primeiro, o código atende a requisitos diferentes e poderíamos considerar atores diferentes. Lê-se atores aqui como os sistemas que usam a aplicação. Em segundo lugar, temos que a solução atual de classes poderia considerar um nível de granularidade(responsabilidade) menor para separar contextos diferentes de forma mais simples.

O SRP traz inicialmente a visão de que uma classe ou componente deveria mudar apenas por um motivo. O que vale reconsiderar é que nesse caso existem dois motivos: dois times diferentes, com objetivos similares mas que estão separados com visões de solução técnica e negocial diferentes.

É justamente deste ponto que Uncle Bob fala sobre responsabilidade única. As vezes temos mais motivações para mudar do que apenas trechos de código em lugares errados ou com algo relacionado a baixa coesão. Um complemento sugerido pelo autor a definição de SRP no livro foi:

Um módulo deve ser responsável por um, e apenas um, ator.

Portanto, podemos ver que a estrutura pelo qual times são organizados pode impactar diretamente no papel do qual se torna a responsabilidade de sistemas utilizados. Em um contexto cada vez mais amplo, remoto e distribuído cenários análogos a esse podem se tornar comum.

Referências

• FREITAS, Bruno C. D. Modernização de sistemas legados para disponibilização em dispositivos móveis com arquitetura baseada em microservices. 2017. Tese (Pós graduação) — Universidade Federal de Pernambuco, [S. l.], 2017.
• Products Not Projects — Blog Martin Fowler
• Clean Architecture