Arquitetura do Sistema

A visão geral e simplificada do projeto pode ser representada pelo diagrama abaixo.

Front-End

Arquitetura

Dado que o fluxo de telas da versão mobile possuir maior complexidade que a versão web, fora criado uma arquitetura diferente para cada, tendo em mente essa dificuldade.

Aplicação Web

A arquitetura selecionada para o front-end web é o MVC (Model-View-Controller). Como a aplicação web possui um fluxo de telas relativamente simples, não é necessário se preocupar em abstrair a lógica de apresentação de telas em uma camada adicional.

Como pode se ver na imagem, o fluxo de informações começa na View, onde todas as informações são exibidas e todas interações do usuário são recebidas. A partir disso, a controller é encarregada de verificar os dados recebidos. Finalmente, na Model, é onde se recebe pedidos da controller para mandar ou receber dados do banco de dados.

Aplicação Mobile

A arquitetura selecionada para o front-end mobile é o MVCR (Model-View-Controller-Router). Como a aplicação web possui um fluxo de telas mais complexo, foi dado um peso a isso, e portanto, foi focado na abstração da lógica de apresentação de telas em uma camada adicional.

Essa arquitetura se assemelha bastante com a MVC utilizada na versão web, com a diferença que agora a View não faz mais o trabalho de exibir as telas. Essa ocupação fica em outra camada (Router).

Como pode se ver na imagem, o fluxo de informações começa na View, onde todas as informações são exibidas e todas interações do usuário são recebidas. A Router, então, se responsabiliza de como exibir novas telas, se necessário. A controller é encarregada de verificar os dados recebidos, e, finalmente, na Model, é onde se recebe pedidos da controller para mandar ou receber dados do banco de dados.

Backend

A camada de backend da aplicação trabalha sobre o padrão de microsserviços, que permite maior escalabilidade e isolamento. Assim, identificar os pontos de falha da aplicação se torna uma tarefa menos onerosa.

Modelagem via DDD

Essa arquitetura é explicada através de uma modelagem chamada DDD (Domain Driver Design), que permite com que se entenda quais os obetivos do business empregado na aplicação, auxiliando o desenvolvimento indicando quais necessidades o mesmo deve suprir. Abaixo está uma aplicação simples dessa modelagem na interpretação dos alunos. Os bounded contexts são traduzidos como microsserviços para o projeto.

Pode-se perceber que existe uma relação de downstream por parte do contexto de voluntários e instituições, e uma relação de upstream de oportunidades para os demais contextos. Isso significa que o contexto de oportunidade é de suma importância para o negócio pelo qual o software deve satisfazer. Ainda pode-se reparar que esta modelagem permite com que se entenda quais as entidades cada contexto é responsável.

Para entender melhor as nomenclaturas do software, esta metodologia também prega pela criação de uma linguagem universal, que deve ser entendida por todos envolvidos no projeto. Esta linguagem facilita o entendimento da aplicação e dos contextos que a envolvem. Assim, criamos um glossário, descrito abaixo.

• USUÁRIO: Pessoa que acessa o aplicativo com a finalidade de usá-lo.
• CLIENTE: Parte da aplicação que proporciona a visualização gráfica e a interação da mesma para o usuário.
• SERVIDOR: Parte da aplicação que responde às necessidades do cliente.
• VOLUNTÁRIO: Usuário que acessa a aplicação com a finalidade de encontrar oportunidades.
• OPORTUNIDADE: Trabalho voluntário disponibilizado por uma instituição.
• INSTITUIÇÃO: Usuário que provê oportunidades para voluntários.
• DESCRIÇÃO: Informações sobre uma determinada entidade do sistema.
• LISTAGEM: Lista de oportunidades disponíveis.
• INTERESSE: Intenção do voluntário em aplicar-se ao trabalho voluntariado especificado em uma oportunidade.
• PERFIL: Parte da aplicação reponsável por manter informações do usuário, podendo este ser representado por um voluntário ou por uma instituição.
• CADASTRO: Parte da aplicação responsável pela criação de um perfil.
• LOGIN: Parte da aplicação responsável pela permissão de acesso a um perfil já cadastrado de um usuário.

Arquitetura dos microsserviços

O padrão arquitetural Layers (Camadas) foi adotado por cada microsserviço constituinte da camada de backend. Sabendo disso, as camadas presentes para este padrão vão de encontro com os conceitos de DDD, portanto têm-se de forma isolada a infraestrutura (infraestructure), os repositórios (repositories), os serviços (services) e as interfaces da aplicação (APIs). Assim, as responsabilidades de cada camada atua de maneira isolada, onde cada a cadeia de dependências se dá através de interfaces bem definidas. O dado que trafega pelas camadas é chamado de entidade, e pode ser identificado como voluntário, oportunidade ou instituição, sendo esta entidade definida de acordo com o microsserviço que a mesma se encontra. Abaixo está uma ilustração genérica que pode representar qualquer um dos três microsserviços.

Definição de rotas

Cada microsserviço oferece todas as funcionalidades CRUD (Create, Read, Update, Delete) que são expostas via uma interface de aplicação (API) no formato REST (portanto, uma API RESTful). Para isso, foram definidas as rotas que serão expostas para que o cliente consiga realizar requisições, listadas abaixo de acordo com o microsserviço ao qual se referentem.

<< TBD >>