No mundo acelerado do desenvolvimento moderno, a arquitetura frequentemente determina se um projeto prospera ou desmorona sob sua própria complexidade. Enquanto muitos desenvolvedores intuitivamente entendem que a arquitetura importa, o "porquê" e o "como" são discutidos com menos frequência. O que torna a arquitetura tão crítica e como você pode garantir que suas escolhas levem à clareza em vez do caos?
O Problema
Imagine começar um novo projeto sem planejar sua arquitetura — apenas mergulhando no código. Você desenvolve seu primeiro módulo, que contém links entre submódulos e componentes. Então, você cria um segundo módulo e o vincula ao primeiro. Esse padrão continua conforme você adiciona mais módulos e conexões.
O problema surge quando você precisa excluir ou editar um módulo. Conforme seu projeto cresce, a complexidade também cresce, com inúmeros módulos, submódulos e conexões borradas entre eles. Eventualmente, essa teia emaranhada se torna uma dor de cabeça para os desenvolvedores e mais cara para a empresa manter.
O que é Arquitetura?
Muitos desenvolvedores pensam erroneamente que arquitetura é equivalente a uma estrutura de pastas, mas isso é incorreto. Arquitetura vai além da organização de arquivos. Ela descreve como módulos e componentes interagem dentro do sistema do projeto.
A arquitetura abrange vários elementos de um projeto, especificando como os módulos e componentes devem ser desenvolvidos e como eles devem se interconectar.
No frontend, os módulos geralmente são componentes de UI que utilizam lógica de negócios. Eles podem variar de componentes grandes, como páginas, a componentes pequenos, como entradas, botões ou tipografia.
O que um ótimo design de software deve ter?
Precisamos garantir que os módulos do nosso projeto tenham:
- Alta coesão — Cada módulo deve conter lógica de negócios relacionada.
- Baixo acoplamento — Os módulos devem ser tão independentes uns dos outros quanto possível.
Coesão se refere ao que o módulo pode fazer. Baixa coesão significaria que a classe faz uma grande variedade de ações — é ampla, sem foco no que deveria fazer. Alta coesão significa que a classe está focada no que deveria estar fazendo, ou seja, apenas métodos relacionados à intenção da classe.
Acoplamento refere-se a quão relacionados ou dependentes dois módulos são um em relação ao outro. Para módulos de acoplamento baixo, alterar algo importante em uma classe não deve afetar a outra. O acoplamento alto tornaria difícil alterar e manter seu código. Como os módulos são intimamente unidos, fazer uma alteração pode exigir uma reformulação completa do sistema.
Essencialmente, alta coesão significa manter partes relacionadas do código juntas em um só lugar. Ao mesmo tempo, baixo acoplamento envolve separar partes não relacionadas da base de código o máximo possível.
Diferentes Cenários de Arquitetura
Alta coesão, alto acoplamento
Vamos considerar o antipadrão God object. Um God object é um módulo que tem múltiplos submódulos e interconexões, enquanto também tenta resolver múltiplas tarefas simultaneamente.
Isso resulta em alta coesão porque um único módulo é responsável por múltiplas tarefas e alto acoplamento devido às conexões confusas entre vários módulos e submódulos.
Baixa coesão, baixo acoplamento
Neste cenário, os módulos são bem divididos, mas os submódulos dentro resolvem tarefas diferentes (indicadas pelas cores diferentes na imagem). No entanto, as conexões entre os módulos ainda não estão claras.
Baixa coesão, alto acoplamento
Este é um caso diferente. Aqui, os módulos são claramente divididos, e as conexões entre eles são sólidas. No entanto, dentro de cada módulo, a coesão é baixa porque eles resolvem múltiplas tarefas, levando a uma complexidade desnecessária.
No entanto, isso ainda é melhor que os dois exemplos anteriores porque você pode remover ou modificar módulos individuais sem muita dificuldade.
Alta coesão, baixo acoplamento — o ideal
Em uma arquitetura ideal, os links entre módulos são "fracos", tornando fácil remover ou modificar qualquer módulo. Dentro de cada módulo, componentes e classes resolvem uma tarefa específica (conforme indicado por sua cor uniforme), e não há mistura de responsabilidades, diferentemente dos exemplos anteriores.
Embora essa arquitetura ideal seja rara em projetos, pois exige conhecimento e experiência específicos, é algo que todos devemos almejar.
Conclusão
Arquitetura é a estrutura de módulos, componentes e as conexões entre eles.
A chave para uma arquitetura bem-sucedida está na implementação de princípios de desenvolvimento como DRY, KISS e SOLID. Remover e modificar módulos deve ser fácil, especialmente a parte de remoção — esse é um ponto importante.
Deixe-me saber se você tiver alguma dúvida ou sobre qual arquitetura você gostaria de saber mais!
