Arquitetura do Frontend

Descrição

O frontend foi desenvolvido utilizando Next.js com React, buscando uma arquitetura componentizada, que facilite manutenção, testes e escalabilidade.
A aplicação segue um padrão de rotas baseado em pastas, aproveitando a estrutura do Next para criação automática de rotas a partir do diretório app/.

Tecnologias

• Next.js → Framework React para rotas e renderização.
• React → Biblioteca de UI, base do frontend.
• Axios → Consumo de APIs.
• Tailwind CSS → Estilização utilitária com paleta customizada.
• ESLint → Padronização de código.
• Docker → Conteinerização do ambiente.
• GitLab → Versionamento, Wiki e CI/CD.

Estrutura de Arquivos do Frontend

Explicativo dos Diretórios

• app/ → raiz da aplicação, organiza as rotas e páginas.
• page.tsx → ponto de entrada de cada rota.
• loading.tsx → tela/estado de carregamento da rota.
• error.tsx → fallback para tratamento de erros da rota.
• components/ → componentes exclusivos da tela, cada um em sua pasta com index, skeleton e error.
• components (nível raiz) → componentes compartilhados entre várias telas.
• lib/ → utilitários gerais (funções auxiliares, hooks globais etc.).

Justificativa da Arquitetura

A arquitetura foi escolhida para:

• Facilitar debug e manutenção, isolando erros e loaders por tela e por componente.
• Seguir o padrão de componentização do React, reaproveitando blocos de UI.
• Permitir futura expansão para testes unitários e testes de integração mais claros, já que erros e estados de loading estão isolados.
• Melhorar a organização visual do projeto, facilitando a navegação pelo código.

Arquitetura do Backend

Descrição

O backend foi desenvolvido utilizando NestJS, um framework Node.js para a construção de aplicações server-side eficientes e escaláveis. A arquitetura adotada é a de Monolito Modular, onde a aplicação é dividida em módulos que representam os domínios de negócio da aplicação (ex: producers, areas, harvests).

Esta abordagem promove uma forte Separação de Responsabilidades (Separation of Concerns), com cada módulo possuindo camadas bem definidas (Controller, Service, Repository), facilitando a manutenção, testabilidade e o desenvolvimento paralelo de novas funcionalidades.

Tecnologias

• NestJS → Framework backend para a estrutura da aplicação, injeção de dependência e modularidade.
• TypeScript → Superset do JavaScript que adiciona tipagem estática, aumentando a robustez do código.
• Prisma → ORM (Object-Relational Mapper) de próxima geração para a comunicação com o banco de dados.
• PostgreSQL → Banco de dados relacional, com a extensão PostGIS para manipulação de dados geoespaciais.
• Docker → Conteinerização do ambiente de desenvolvimento e produção.
• Swagger → Geração automática de documentação da API a partir do código.
• Passport.js → Middleware para estratégias de autenticação (JWT).
• ESLint / Prettier → Padronização e formatação de código.
• GitLab → Versionamento, Wiki e CI/CD.

Estrutura de Arquivos do Backend

Diagrama de Sistema

Padrões de Projeto e Explicação das Camadas

A arquitetura se baseia em um conjunto de padrões de projeto para garantir um código limpo, desacoplado e manutenível.

Padrões Fundamentais

• Arquitetura Modular: O sistema é dividido em módulos de domínio independentes (ProducersModule, AreasModule). Cada módulo encapsula um conjunto coeso de funcionalidades.
• Injeção de Dependência (DI): Utilizada nativamente pelo NestJS, permite que as dependências de uma classe (como um Service precisando de um Repository) sejam "injetadas" externamente, em vez de serem criadas internamente. Isso desacopla o código e facilita enormemente os testes.
• Repository Pattern: A camada de Service (lógica de negócio) não se comunica diretamente com o ORM (Prisma). Em vez disso, ela depende de uma abstração (o Repository), que centraliza e encapsula todas as consultas ao banco de dados. Isso isola a lógica de negócio dos detalhes de implementação da persistência.
• DTO (Data Transfer Object): Classes que definem a estrutura de dados que trafegam nas fronteiras da aplicação (ex: corpo de uma requisição HTTP). São usadas com os ValidationPipes do NestJS para garantir a integridade dos dados que entram no sistema.

Explicativo das Camadas

• *.controller.ts (Camada de API) → Responsável por receber requisições HTTP, validar os dados de entrada através de DTOs e direcionar a chamada para a camada de serviço. Não contém regras de negócio.
• *.service.ts (Camada de Serviço) → Contém a lógica de negócio principal. Orquestra as regras, cálculos e decisões. É o "cérebro" de cada módulo e depende dos Repositories para manipular dados.
• *.repository.ts (Camada de Acesso a Dados) → Abstrai a comunicação com o banco de dados. Centraliza as queries (especialmente as mais complexas) e garante que o restante da aplicação não precise "saber" que o Prisma está sendo usado.
• *.spec.ts (Camada de Testes) → Arquivos de testes unitários que vivem ao lado do código que testam, garantindo a qualidade e o comportamento esperado de cada unidade (Service, Controller, etc.).

Justificativa da Arquitetura

A arquitetura do backend foi projetada com os seguintes objetivos:

• Manutenibilidade e Escalabilidade → A divisão em módulos por domínio permite que a equipe encontre, corrija e adicione funcionalidades de forma isolada e segura, sem impactar o resto do sistema.
• Separação de Responsabilidades (SoC) → Cada camada tem um propósito claro. Controllers não acessam o banco, e Services não lidam com HTTP. Isso torna o código mais limpo, previsível e fácil de raciocinar.
• Testabilidade → A Injeção de Dependência e o Repository Pattern facilitam a criação de testes unitários, permitindo "mockar" (simular) o acesso ao banco para testar a lógica de negócio de forma isolada.
• Robustez → O uso de DTOs com validação automática na camada de Controller garante a integridade dos dados na entrada da API, prevenindo a propagação de dados inválidos para as camadas internas.