Construindo Interfaces Impecáveis

A arquitetura limpa ou clean architecture, é um conceito desenvolvido por Robert C. Martin que visa criar sistemas modulares e independentes de frameworks, facilitando a manutenção, testabilidade e escalabilidade do código.

Bom, essa é a definição mais simples que encontramos em uma leve pesquisa no google, porém como aplicar isso no frontend ? Visto que quando se fala de arquitetura de software, parece muito mais "encaixável" no backend. É isso que discutiremos em sequência.

Trabalhando um bom tempo com criação de interfaces e utilizando diversas ferramentas como React, Angular e Vue, veremos que sempre tentamos separar a "camada" de UI dos casos de uso (lógica de negócio ou domínio), mas isso faz sentido ? Todo projeto é assim ? Essas são varias perguntas que surgem e alias a resposta pra elas não existe, tudo depende do contexto do seu projeto.

Vamos a um exemplo prático:

O google docs, word e excel tem ferramentas de busca por texto e recorrência. Nesse sentido a regra "Buscar por texto ou recorrência" é um caso de uso do domínio, então se separarmos UI da lógica nesse contexto e levando em consideração essa regra para nosso software, faz sentido eu mandar um texto para o backend buscar as recorrências e me devolver isso ? A resposta é: não. Isso seria muito custoso.

No contexto de projetos frontend, a clean architecture busca separar as preocupações e responsabilidades de cada camada do sistema, promovendo a organização e a clareza do código. Vamos explorar como ela pode ser implementada em um projeto de frontend.

1. Entidades:

• Para nós, as entidades representam o núcleo do domínio da aplicação e devem ser independentes da interface do usuário, como já descrito acima devemos ao máximo diferenciar UI de regra de negócio. Alguns exemplos do frontent: Modelos de dados ou objetos (types) que representam entidades de negócio.

2. Casos de uso:

• Esses casos, são as nossas famosas regras de negócio, se no contexto do seu software isso estiver contido no frontend eles não devem depender de detalhes de implementação, como nossos frameworks e bibliotecas. Os casos de uso no frontend podem abranger então a lógica da aplicação, manipulação de dados e chamadas a API.

3. Interface de usuário (UI):

• Aqui fica toda a apresentação visual e interação com o usuário. Nesse contexto estão nossos componentes, estilos e manipulação de eventos. A ideia aqui, é que essa camada seja minimamente dependente das camadas mais internas, como os casos de uso e entidades, é como falamos, sempre tentar separar lógica de negócio de UI.

4. Frameworks e Drivers:

• A camada mais externa é composta por nossa infraestrutura, nossos frameworks e bibliotecas, e isso deve ser o mais isolado possível, lembrando que tratando desse padrão de arquitetura, nosso software precisa funcionar independente das suas tecnologias usadas. Aqui no front essa camada seria o React, Angular ou Vue como exemplos.

Vamos por isso no papel e trazer um desenho de como essas camadas podem ficar no nosso projeto.

Agora precisamos saber, o porque de separar em camadas assim e eu vos digo agora, quais os benefícios de ser um pouco mais chato e tentar trazer isso para dentro do seu software.

• Testabilidade: Aqui conseguimos separar UI de casos de uso, então como elas estão isoladas e não dependem diretamente uma da outra, sendo assim fácil de testar.
• Manutenibilidade: A separação das camadas da aplicação facilitam a manutenção de código, uma vez que alterações em uma camada não devem afetar as outras.
• Reusabilidade: A modularidade dessa arquitetura permite reutilizar componentes em diferentes partes da aplicação ou até mesmo em outros projetos.

Isso é um pouco do que esse padrão tende a nos oferecer, tem muito mais que pode ser abordado. Ao adotar a arquitetura limpa no seu frontend, você consegue criar aplicações mais robustas, escaláveis e de fácil manutenção, contribuindo com um código mais limpo e sustentável ao longo do tempo. Bom é isso ai e até mais! 👋