Por Tiago Chaves

Revisão de Eric Braga

AllowMe

Há um tempo atrás recebi um desafio dos meus gestores: re-implementar o nosso SDK utilizando Swift e empregando uma arquitetura nova que nos permitisse, e colaborasse, para ter uma alta cobertura de testes unitários. De cara já pensei na Clean Swift, idealizada por Raymond Law, que eu já havia utilizado em alguns apps com propósito de prática. Porém, a Clean Swift,é baseada em um ciclo VIP (View -> Interactor -> Presenter), algo de que eu não precisava de fato, apesar de ser possível aproveitar alguns de seus pontos… a solução de fato foi fazer algo que eu já deveria ter feito: estudar a Arquitetura Limpa na fonte, ou seja, estudar o famoso livro Arquitetura Limpa, de Robert C. Martin (a.k.a, Uncle Bob)!

E realmente, com base na arquitetura limpa “pura” pude ter uma visão mais clara e aprofundada da sua proposta e assim me senti confortável em criar uma independência na sua utilização. Seja para fazer um app, um SDK ou um software qualquer, esse novo conhecimento deixou claro que ela se adequa exatamente no que eu precisava! Com base nisso gostaria de passar um pouco da minha visão sobre esta arquitetura.

Antes de começar, porém, aqui vai uma premissa muito importante: ela NÃO é algo aplicável, em qualquer situação! Isso se deve ao fato da arquitetura limpa ser muito desafiadora na implantação, requerer um certo grau de conhecimento e alguns princípios por parte de todos os devs que irão codificar a solução, ou seja, para quem já conhece os princípios utilizados (mesmo sem conhecer a arquitetura limpa) o ganho é alto, com um melhor desenvolvimento de código e entendimento não só da arquitetura mas também da Orientação a Objeto; porém, uma equipe um pouco menos experiente, talvez não irá usufruir completamente dos benefícios da prática, podendo gerar mais problemas, confusões e trabalho extra do que soluções.

Partindo dessa premissa vamos entender não só os desafios, mas também os benefícios que a arquitetura limpa, quando bem implementada, nos traz. Bora lá!

 

A arquitetura usa um grande número de princípios

Para compreender a arquitetura limpa e fazer bom uso de seus conceitos é necessário conhecer alguns princípios, que são abordados no próprio livro. Entre eles estão:

S.O.L.I.D.

– SRP: Single Responsibility Principle

– OCP: Open/Closed Principle

– LSP: Liskov Substitution Principle

– ISP: Interface Segregation Principle

– DIP: Dependency Inversion Principle

– CCP: Common Closure Principle

– CRP: Common Reuse Principle

– SAP: Stable Abstraction Principle

Esses são os que acredito serem os mais importantes para uma boa compreensão da solução proposta por Uncle Bob e, como podemos ver, não é algo que todos os devs compreendam, porém, os que já compreendem tendem a gerar códigos cada vez melhores e mais coerentes independente do uso, ou não, da arquitetura limpa!

A arquitetura limpa gera MUITOS componentes

Um dos conceitos abordados no livro é que cada caso de uso (i.e. Login, List Orders, Purchase, etc) deve ter seu próprio conjunto de componentes fixos, ou seja, para cada caso de uso teremos +- 6 componentes! Mesmo sendo componentes relativamente pequenos em sua maioria, isso gera um certo trabalho, não sendo recomendado para casos de uso (ou softwares) muito simples ou que não vão ter uma continuação/manutenção (hackatons, PoCs, etc). Apesar de todo esse trabalho, uma vez implementados você usufrui dos benefícios do princípio SRP (Single Responsibility Principle) implantado, facilitando a leitura do caso de uso, a manutenção dos componentes e nos testes!

Arquitetura limpa

Vamos agora à famosa imagem da arquitetura limpa demonstrada abaixo:

Fonte: Livro Clean Architecture

Na imagem podemos ver o conceito base da arquitetura limpa, que é: As dependências de código devem apontar para dentro, na direção das políticas de nível mais alto! Isso significa que suas regras de negócios (entidades) no centro da imagem não devem conhecer os componentes de mais baixo nível e sim o contrário! Isso implica em componentes limitados a apenas uma camada onde os componentes mais externos podem depender dos mais internos, porém, os mais internos não devem conhecer os mais externos, por exemplo: Uma tela (considerada camada mais externa) pode depender de um controller (camada mais interna), porém, o oposto não deve ocorrer. Isso torna o nosso software mais estável e robusto uma vez que não importa quem vai me fornecer o dado vindo de uma camada mais externa; eu não o conheço, porém, sei o que ele deve fazer!

A mágica disso tudo é que você tem um software com uma arquitetura plug-in, sendo possível trocar os componentes das camadas mais externas sem impactar os componentes de mais alto nível.

O casamento perfeito: Test-Driven Design(TDD) e Arquitetura limpa

Como a arquitetura limpa é separada em camadas de componentes independentes isso vira um cenário que facilita, e muito, a aplicação de testes unitários – e, claro, uma metodologia excepcional para escrever os testes é o TDD (Test Driven Design). O objetivo aqui não é explicar nada sobre o TDD (se você não conhece, aconselho a ler algum artigo, ou livro, sobre! Indico o Test Driven Development: By Example de Kent Beck) e afirmo que a implementação da arquitetura limpa facilita a sua aplicação por alguns motivos:

  • Os componentes tendem a ser classes pequenas e responsáveis por um assunto apenas;
  • Como os componentes são independentes, você pode testar pequenos trechos do código antes de ter o “todo” completo;
  • Como os componentes usam interfaces é MUITO simples criar um mock para isolar os testes unitários para apenas aquele componente.

Bom esses são os pontos que aprendi estudando a Arquitetura Limpa e implantando ela no iOS. Caso eu tenha despertado a curiosidade de vocês em conhecê-la melhor, recomendo fortemente a leitura do livro, onde é possível encontrar muitos outros princípios e conceitos importantes na hora de pensar e implementar a arquitetura do seu software!

Abraço!

Tiago Chaves