Matheus Castiglioni

Aviso

A partir de 10/02/2022 o blog foi descontinuado em favor ao meu canal no youtube, ou seja, não haverá novas publicações.

Irei dedicar e focar exclusivamente no meu canal para criação e compartilhamento de conteúdo, se você tem interesse em continuar me acompanhando peço por favor que se inscreva no canal.

Screaming Architecture

Imagine que você está procurando por plantas de uma construção, tal documento foi criado por uma pessoa arquiteta e o mesmo nos diz os planos para a construção em si. Mas, quais são esses planos ditos pelas plantas?

Se a planta que você está olhando é para uma residência de uma única família, então você irá provavelmente ver uma entrada, uma sala de estar, uma sala de jantar, uma cozinha, quartos e por ai vai… Repare a planta por si só está gritando: Casa.

Porém, se a planta que você está olhando é para uma biblioteca, então você irá ver uma grande entrada, uma área para pagamentos, uma área de leitura, pequenas salas de conferências, galeria com estantes de livros e por ai vai… Repare a planta por si só está gritando: Biblioteca.

Seguindo esses princípios, quando você olha para a arquitetura da sua aplicação (front-end/mobile) ou serviço (back-end), o que ela está gritando? Quando você olha em diretórios e arquivos de alto nível, o que eles gritam? Se sua arquitetura segue a ideia de screaming architecture (arquitetura gritante) então eles deveriam gritar coisas como: Sistema de saúde, Sistema de pagamento, Sistema de inventário, Sistema de passagem, etc…

Porém, muitas vezes sua arquitetura irá gritar coisas como: Spring, Rails, Nest, Django, Phoenix, React, Svelte, etc…

Orientada à casos de usos e negócio

Uma arquitetura não deveria ser sobre frameworks ou bibliotecas e sim sobre negócio e seus casos de uso (use case driven). Frameworks e bibliotecas são apenas ferramentas e meios de construção, se a arquitetura é baseada neles, então ela não pode ser baseada no negócio.

A razão para que ela seja centrada em negócio e seus casos de uso é para que você não se comprometa com tais tecnologias, se um dia você precisar migrá-las isso deveria ser uma missão possível. Além disso, você deveria poder postegar ou atrasar algumas tomadas de decisões, por exemplo: Rabbit ou Kafka? MySQL ou MongoDB? Hibernate ou JPA? etc… Quando você é conduzido por frameworks, eles irão tomar tais decisões por você e irão decidí-las bem mais cedo do que deveriam.

Qualidade

Além disso, quando sua arquitetura é orientada ao negócio, é mais fácil testá-las, você não precisa criar burocracias ou barreiras impostas por tecnologia X, Y ou Z. Você não deveria precisar conectar em um banco de dados para rodar seus testes unitários, seus casos de usos deveriam ser objetos de negócio e eles deveriam ser testados facilmente de forma isolada, sem conhecimentos do mundo externo.

Conclusão

Nesse post vimos um estilo de arquitetura chamada screaming architecture, nela vimos que a arquitetura deve ser centrada e conduzida pelo negócio e seus casos de usos e não por tecnologias. Ou seja, quando você olhar a estrutura do seu projeto, ela deveria gritar seu propósito.

Abraços, até a próxima.

Matheus Castiglioni

Matheus Castiglioni

Apaixonado pelo mundo dos códigos e um eterno estudante, gosto de aprender e saber um pouco de tudo, aquela curiosidade de saber como tudo funciona, tento compartilhar o máximo de conhecimentos adquiridos e ajudar todos aqueles que sou capaz.

comments powered by Disqus