O que é Screaming Architecture?

Screaming Architecture é um termo utilizado por Robert C. Martin que enfatiza a clareza e a simplicidade do código e se baseia no princípio de que o código deve ser fácil de ler e entender. O nome “Screaming Architecture” vem do fato de que o código deve “gritar” sua intenção, ou seja, deve ser claro e fácil de entender.

Princípios do Screaming Architecture

O Screaming Architecture é baseado em quatro princípios:

• Independência: Os componentes do sistema devem ser independentes uns dos outros. Isso significa que cada componente deve ser capaz de funcionar de forma independente, sem depender de outros componentes.
• Testabilidade: O código deve ser fácil de testar. Isso significa que cada componente deve ser testável de forma independente, sem depender de outros componentes.
• Clareza: O código deve ser claro e fácil de entender, ou seja, cada componente deve “gritar” sua intenção.
• Simplicidade: O código deve ser simples e direto. Isso significa que cada componente deve ser simples e direto, sem excesso de complexidade.

Classes específicas por operação no Screaming Architecture

Uma das práticas recomendadas pelo Screaming Architecture é a criação de classes específicas por operação. Em vez de ter uma única classe denominada “service” com várias responsabilidades, é recomendado criar classes específicas para cada operação.

Por exemplo, em vez de ter uma única classe “OrderService” que lida com todas as operações relacionadas a pedidos, a recomendação é criar classes específicas para cada operação, como “CreateOrder”, “RefundOrder” e “AuthorizeUser”. Cada classe seria responsável por uma única operação e seria independente das outras classes.

Isso torna o código mais claro e fácil de entender, pois cada classe tem uma única responsabilidade e é fácil de testar de forma independente.

Leia também:

O que é Squad as a Service? Saiba quando é hora de contratar

5 ferramentas de IA generativa para desenvolvimento de soluções tecnológicas

Exemplos de criação de classes

No exemplo a seguir, toda a lógica do pedido está concentrada em uma classe. Se precisar alterar o método de criação de pedido, você estára mexendo no mesmo arquivo que contém a regra de autotização e estorno, podendo inserir um bug sem intenção, ou ao menos tendo que se preocupar com outras operações que estão no mesmo lugar, tornando difícil entender as alterações.

Com o tempo, a classe OrderService, ao acumular mais funções, tende a crescer, ganhar mais dependências e ficar mais complexa. Isso dificulta tanto o entendimento quanto os testes, pois para testar algo específico como o estorno, é necessário instanciar a classe inteira, incluindo dependências não relevantes para o caso.

No exemplo da próxima imagem, temos três classes separadas, cada uma responsável por uma operação: criação do pedido, estorno e autorização. Se precisar alterar algo no estorno, não se mexe nas outras operações.

Isso simplifica os testes, pois cada classe só contém o código necessário para sua operação específica. Além disso, se várias pessoas estiverem trabalhando no projeto, é menos provável que mexam no mesmo código ao mesmo tempo, pois as operações são separadas.

Assim, se houver um problema na criação e na autorização, duas pessoas diferentes podem corrigi-lo sem interferir uma na outra, conforme mencionado por Robert Martin em seu livro Arquitetura Limpa, referindo-se a estas como classes de caso de uso.

Conclusão

Em resumo, o Screaming Architecture é um padrão de arquitetura de software que enfatiza a clareza e a simplicidade do código. Uma das práticas recomendadas pelo Screaming Architecture é a criação de classes específicas por operação, chamadas Caso de Uso, em vez de uma única classe denominada Service com várias responsabilidades.

Dessa forma, o código se torna mais claro e fácil de entender, pois cada classe tem uma única responsabilidade e é fácil de testar de forma independente. A implementação de classes específicas por operação em Kotlin é simples e direta, como mostrado no exemplo de código.

Assim, ao seguir os princípios do Screaming Architecture, é possível criar um código mais independente, testável, claro e simples. Conte com nossos times de especialistas em Screaming Architecture e acelere os resultados da sua empresa!

 

Texto: Eder Matos

Edição e revisão: Priscila Jansen