Arquitetura

Foi escolhido o modelo C4 de documentação para arquitetura de software. Esse modelo consiste em um conjunto hierárquico de diagramas de arquitetura de software para contexto, containers, componentes e código.

A hierarquia dos diagramas C4 fornece diferentes níveis de abstração e cada um deles é relevante para um público alvo.

O motivo da escolha desse modelo é devido a sua facilidade de desenvolvimento e entendimento pelas partes envolvidas.

Nível 1 - Diagrama de Contexto do Sistema

O diagrama de contexto mostra o sistema que está sendo construído. No diagrama, todos os usuários fazem uso de uma mesma aplicação, sendo seu fluxo de execução distinguido internamente. A aplicação por sua vez faz as requisições para a API.

Figura 1: Diagrama de contexto

Nível 2 - Diagrama de Container

O diagrama de container amplia o sistema de software e mostra os containers (aplicativos, armazenamentos de dados, serviços, etc.) que compõem esse sistema de software. Aqui já é possível ver algumas decisões de tecnologias, decisões de arquitetura e a comunicação entre os serviços.

Figura 2: Diagrama de container

Nível 3 - Diagrama de Componentes

O diagrama de componentes amplia um container individual para mostrar os componentes dentro dele.

A seguir, na figura 4, é apresentado um exemplo da arquitetura interna do aplicativo e onde ocorre a comunicação com o servidor. Na figura 5 é a arquitetura do servidor (API) e sua comunicação com o banco de dados e o retorno para o cliente.

Figura 3: Diagrama de componente: comunicação API, banco de dados e aplicativo

Figura 4: Diagrama de componente: comunicação API, banco de dados e aplicação

Nível 4 - Código e Padrões de Arquitetura

O último nível é o 4. Aqui a arquitetura é detalhada a nível de código e implementação. O padrão de arquitetura utilizada foi o de cliente-servidor em conjunto com a arquitetura REST para a construção da api e a integração com o frontend.

O modelo de cliente-servidor é uma estrutura de aplicação distribuída que distribui as tarefas e cargas de trabalho entre os fornecedores de um recurso ou serviço, designados como servidores, e os requerentes dos serviços, designados como clientes.

O objetivo desta divisão é separar a arquitetura e responsabilidades em dois ambientes. Assim, o cliente (consumidor do serviço) não se preocupa com tarefas do tipo: comunicação com banco de dados, gerenciamento de cache, log, etc. E o contrário também é válido, o servidor (provedor do serviço) não se preocupa com tarefas como: interface e experiência do usuário. Permitindo, assim, a evolução independente das duas arquiteturas.

A API, implementada em node.js, é a responsável por tratar os dados e fazer a conexão das informações entre a aplicação web (frontend) e o banco de dados. A organização foi pensada em três camadas: Routes, Controllers.

Figura 5: Organização da API em Routes, Controllers

A camada de Routes é composta por todas as rotas da API que são expostas aos clientes para fazer a conexão via HTTP. A camada de Controller é a responsável pela lógica de negócio da aplicação. Toda rota definida em Router possui uma instância de Controller associada, responsável por sua lógica de negócio.

Para a aplicação web, implementada com o framework React, foi seguido o padrão de Component Based Architecture (Arquitetura Baseada em Componentes).

A organização foi pensada a partir do conceito de web components, onde cada "parte" da tela é um componente independente, customizável e que pode ser reutilizável em qualquer outra parte da aplicação. No exemplo a seguir, temos um exemplo da utilização de componentes no projeto representado como uma "árvore", tal qual a estrutura de dados.

Figura 6: Representação de web components

Este tipo de arquitetura encapsula partes individuais de uma interface (componentes) em sistemas independentes e auto-sustentáveis. Para o uso dessa arquitetura, os componentes precisam:

• Ser independentes;
• Interagir com outros componentes no mesmo espaço, sem afetar ou ser afetado pelo outro;
• Possuir sua própria estrutura, métodos e atributos;
• Ser reutilizável em qualquer outro lugar da aplicação.