Descrição da arquitetura deste projeto

Metodologia adotada

Para o desenvolvimento deste projeto algumas técnicas, princípios e padrões foram utilizados para manter um bom nível de organização, manutenção e robustez tanto na arquitetura do projeto quanto no código fonte. Os tópicos abaixo descrevem, brevemente, como a arquitetura do projeto será desenvolvida:

Princípio SOLID

O princípio base utilizado neste projeto é o SOLID.

Para ficarmos de acordo com os princípios descritos no SOLID vamos usar as seguintes técnicas:

• Implementação baseada no Clean Code - Esta forma de implementar visa atender ao princípio S do SOLID, Single Responsability, que garantirá que uma classe terá uma, e somente uma, responsabilidade. Vale ressaltar que, utilizando esta técnica, teremos um projeto com muitas classes com poucas linhas cada uma. Muito questionam esta implementação pois a árvore de arquivos do projeto fica muito extensa, porém, ao meu ver, os benefícios gerados com a facilidade de visualizar e dar manutenção em uma classe com poucas linhas de código e uma única responsabilidade, superam qualquer "incômodo" gerado pela grande quantidade de arquivos.

• Implementação orientada à Interface - Toda comunicação entre classes será, obrigatoriamente, realiazada através de interfaces. Esta técnica permite que o princípio open-closed, letra O do SOLID, seja aplicado corretamente no decorrer da implementação. No caso, para este projeto de iOS, as interfaces são denominadas protocol. Os nossos contratos serão assinados nestas classes protocol. Um ponto importante sobre o uso desta técnica de implementação, somado à prática de Clean code, é o fato de conseguirmos associar o princípio O com o princípio I. Como manteremos nosso código clean, conesquentemente, iremos segregar nossas interfaces.

• Para a implementação dos requests/responses que realizaremos nas API's vamos utilizar o princípio L, Liskov Substitution, do SOLID para garantirmos uma aplicação 100% saudável (sem crash). Toda requisição no qual dependeremos de resultado de terceiros implementará este princípio, esperando um comportamento bem definido destas classes. Se por algum motivo alguma implementação destas classes de terceiros altere o retorno das chamadas receberemos avisos e não seremos pegos de surpresa com um crash ou um erro genérico para o usuário.

• Para cumprirmos com o princípio D, Dependency Inversion, do SOLID vamos, mais uma vez, aproveitar da implementação orientada à interfaces. As dependências entre as classes devem, obrigatoriamente, serem feitas através de interfaces, para que a superclasse não conheça detalhes da implementação da classe no qual ela está se relacionando. Todo o acesso à funcionalidades de qualquer classe deve ser feito através das assinaturas das interfaces e não pela implementação direta dos métodos/atributos/propriedades.

Especialização da arquitetura VIPER

A palavra VIPER é um acrônimo para View, Interactor, Presenter, Entity e Routing.

A arquitetura VIPER é uma forma especializada da arquitetura Clean aplicada para iOS apps. A arquitetura Clean divide uma estrutura lógica de um app em camadas de responsabilidades. Isto faz com que isolemos de forma fácil as dependências, como por exemplo: database, acesso a API e etc. Com este isolamento de dependências a realização de testes automatizados e interações entre as camadas fica muito mais fácil.

Abaixo temos uma breve descrição sobre cada camada do VIPER:

• View: exibe o que é informado pelo presenter e transmite a entrada do usuário de volta para o presenter.
• Interactor: contém a lógica de negócio conforme especificado por um caso de uso.
• Presenter: contém a lógica da visão para preparar o conteúdo que será exibido (como os dados recebidos do interactor) e reage às ações do usuário (como solicitar novos dados do interactor).
• Entity: contém objetos de modelo básicos usados pelo Interactor.
• Routing: contém a lógica de navegação para descrever quais telas são mostradas em qual ordem.

O artigo no qual tomei como base para estudo (você pode ler o artigo completo aqui: Architecting iOS Apps with VIPER), possui a seguinte recomendação:

While the components of VIPER can be implemented in an application in any order, we’ve chosen to introduce the components in the order that we recommend implementing them. You’ll notice that this order is roughly consistent with the process of building an entire application, which starts with discussing what the product needs to do, followed by how a user will interact with it.

Esta ordem de implementação que eles sugerem segue o seguinte fluxo:

• Interactor -> Entity -> Presenter -> View -> Routing

Proposta de arquitetura deste projeto

Explicar aqui sobre a estrutura/arquitetura adotada neste projeto.

• Interactor não pode ser genérico, pois ele conterá as regras de negócio aplicadas a cada caso de uso
• Entity não pode ser genérico também, pois são as classes de domínio do projeto (neste caso não teremos uma pasta Entity no módulo Generics).