Giovanni Gonçalves Migon
Documentação do negócio
Documentação técnica
\mathbb{ARQUITETURA}
Esta seção é dedicada a apresentar a arquitetura definida para o projeto.
Sendo esta dividida nas seguintes partes:
⚙ Backend
Com base nos princípios de Clean Architecture[1], estruturamos um projeto Backend utilizando a seguinte Stack:
Do qual possui uma arquitetura em camadas, das quais são caracterizadas pelos seguintes ficheiros:
Controllers
São responsáveis por prover serviços, e por conectar os demais módulos pertinentes do sistema, com a aplicação backend.
Services
Camada intermediária da aplicação, a qual define a comunicação entre Controllers e Repositories, provendo uma conversão mútua da lógica de sistema, com a lógica de negócio.
Repositories
Define as lógicas diretamente estruturadas com a troca de dados, entre a aplicação backend e o banco de dados.
Prisma
Este ficheiro define a camada de Models, a qual tem por função detalhar o formato dos dados transitados com o banco de dados. E o mesmo, é assim denominado por fazer uso do Prisma, uma biblioteca de ORM (Object Relational Mapping) que provê serviços de query para simplificar a gerência sobre o banco de dados.
Link para o Repositório: Backend
📱 Frontend Mobile
Com base nos princípios de Clean Architecture[1], estruturamos um projeto Mobile utilizando a seguinte Stack:
Do qual possui uma arquitetura em camadas, das quais são caracterizadas pelos seguintes diretórios:
Components
Descrevem elementos visuais independentes, os quais possuem uma lógica descrita internamente, em cada componente. Também há componentes que se utilizam de outros componentes, tornando-se um componente de maior complexidade. Os componentes asseguram que o código seja desacoplado, flexível, reutilizável, e de fácil manutenção. Atualmente, é usual organizá-los em uma página para a estruturação dela.
Hooks
Assim como Components, os Hooks permitem reunir diversas lógicas para um único código, proporcionando características idênticas aos Components, ou seja, código desacoplado, flexível, reutilizável, e de fácil manutenção.
Pages
São as telas da aplicação. Onde reunimos os Components e Hooks a fim de organizar os módulos do sistema na página.
Services
É a camada responsável por dispor serviços para a aplicação. Dentre eles, estão as funcionalidades do Firebase.
Link para o Repositório: Mobile
💻 Frontend Web
Com base nos princípios de Clean Architecture[1], estruturamos um projeto Web utilizando a seguinte Stack:
Do qual possui uma arquitetura em camadas, das quais são caracterizadas pelas seguintes pastas:
Components
Descrevem elementos visuais independentes, os quais possuem uma lógica descrita internamente, em cada componente. Também há componentes que se utilizam de outros componentes, tornando-se um componente de maior complexidade. Os componentes asseguram que o código seja desacoplado, flexível, reutilizável, e de fácil manutenção. Atualmente, é usual organizá-los em uma página para a estruturação dela.
Contexts
Permite estrututrar os dados da aplicação e facilitar o uso para as demais camadas. De maneira geral, ele torna "global" o acesso aos dados,
Hooks
Assim como Components, os Hooks permitem reunir diversas lógicas para um único código, proporcionando características idênticas aos Components, ou seja, código desacoplado, flexível, reutilizável, e de fácil manutenção.
Pages
São as telas da aplicação. Onde reunimos os Components e Hooks a fim de organizar os módulos do sistema na página.
Services
É a camada responsável por dispor serviços para a aplicação. Dentre eles, estão as funcionalidades do Firebase.
Types
Descrevem as entidades da aplicação, que descrevem a lógica de negócio do sistema.
Link para o Repositório: Web
🚀 Diagrama de Deploy
O diagrama a seguir apresenta a arquitetura em alto nível e o processo de deploy da infraestrutura do projeto:
Sobre duas instâncias da AWS, os códigos dos repositórios Frontend Web e Backend serão carregados pelo Gitlab Runner a cada nova contruibuição, e serão armazenados dentro dos respectivos containers Docker.
O repositório do Frontend Mobile não necessita de um servidor por este utilizar o framework do EXPO GO, que é carregado diretamente no smartphone de cada usuário quando o código é executado. O mesmo é apresentado no Firebase, sendo um banco de dados provisionado na Google Cloud.
Os principais módulos do sistema vão dispor de conexões distintas entre sí, das quais sofrerão alterações mediante o andamento dos projetos.
Arquivo XML para o Diagrams.net
💸 Orçamento AWS
Essa seção apresenta o orçamento da infraestrutura na AWS. O orçamento foi feito utilizando a ferramenta AWS Pricing Calculator e busca estimar o custo financeiro para manter a infraestrutura do projeto pelo pelo período de 1 semestre, sendo este a duração do projeto e da disciplina da AGES.
O PDF gerado através do AWS Pricing Calculator com o orçamento para a infraestrutura do projeto pode ser encontrado nesse link: My_Estimate_-_AWS_Pricing_Calculator.pdf
A seguir serão apresentados os componentes (serviços da AWS) que irão compor a infraestrutura do projeto:
-
AWS Advance EC2 instance (t4g.nano)
-
AWS Advance EC2 instance (t2.medium)
Resumo Geral: Para manter a infraestrutura do projeto por 1 semestre, esse será o custo financeiro estimado a cada mês e ao final do semestre:
- Custo Imediato: 549.25 USD
- Custo Mensal: 3.07 USD
- Custo Semestral: 18,42 USD
Referências
[1] C. Martin, Robert. Clean Architecture: A Craftsman's Guide to Software Structure and Design. Pearson, 2017