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

src/
├── app/
├── page.tsx
├── globals.css
├── layout.tsx
├── screen1/
│   ├── page.tsx
│   ├── loading.tsx
│   ├── error.tsx
│   └── components/
│       ├── component1/
│       │   ├── index.tsx
│       │   ├── skeleton.tsx
│       │   └── error.tsx
│       └── component2/
│           ├── index.tsx
│           ├── skeleton.tsx
│           └── error.tsx
├── screen2/
│   ├── page.tsx
│   ├── loading.tsx
│   └── error.tsx
└── components/
    └── lib/

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

aiprodutor-backend/
├── prisma/
│   ├── migrations/
│   └── schema.prisma
├── src/
│   ├── main.ts
│   ├── app.module.ts
│   ├── auth/
│   │   ├── dto/
│   │   ├── guards/
│   │   ├── strategies/
│   │   ├── auth.controller.ts
│   │   ├── auth.controller.spec.ts
│   │   ├── auth.service.ts
│   │   ├── auth.service.spec.ts
│   │   └── auth.module.ts
│   └── ... (demais módulos de dominio como `producers`, `areas`, etc.)
├── shared/
│   ├── prisma/
│   └── config/
└── test/
    ├── auth.e2e-spec.ts
    └── jest-e2e.json

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.

Arquitetura AWS - AI Produtor

Visão Geral

A aplicação AI Produtor é hospedada na AWS utilizando uma arquitetura moderna e escalável que combina serviços gerenciados para garantir alta disponibilidade, segurança e desempenho. A infraestrutura segue o modelo serverless onde possível, reduzindo custos operacionais e simplificando a manutenção.

Diagrama de Deploy

Serviços AWS Utilizados

1. AWS Amplify (Hospedagem do Frontend)

Função: Hospedagem e deploy contínuo da aplicação Next.js

Configuração:

• Deploy automático a partir do repositório GitLab
• Branch main → ambiente de produção
• Branchs de desenvolvimento → ambientes preview

Vantagens:

• CI/CD integrado sem configuração adicional
• SSL automático com HTTPS
• Cache inteligente e CDN integrado
• Escalabilidade automática

2. Amazon Route 53 (Serviço de DNS)

Função: Gerenciamento de domínios e roteamento de tráfego

Configuração:

• Domínio principal: ai-produtor.com
• Subdomínio API: api.ai-produtor.com
• Records A apontando para Amplify e API Gateway

Vantagens:

• Alta disponibilidade e confiabilidade
• Health checking e failover automático
• Integração com certificados SSL

3. Amazon API Gateway (Gerenciamento de API)

Função: Entry point para todas as requisições do backend

Configuração:

• REST API com recursos organizados por domínio
• Configuração de CORS para o domínio do Amplify
• Throttling e rate limiting
• Logging detalhado com CloudWatch

Endpoints Principais:

• POST /auth/login
• GET /producers
• POST /areas
• GET /harvests

4. AWS Lambda (Execução do Backend)

Função: Execução da aplicação NestJS em ambiente serverless

Configuração:

• Runtime: Node.js 18.x
• Memory: 1024MB (ajustável conforme necessidade)
• Timeout: 30 segundos
• VPC configuration para acesso ao RDS

Integração:

• Cada rota do API Gateway invoca uma função Lambda
• Arquitetura de monólito serverless (single Lambda)
• Cold start mitigation strategies

5. Amazon RDS (Banco de Dados)

Função: Armazenamento persistente dos dados da aplicação

Configuração:

• Engine: PostgreSQL 15+
• Extensão: PostGIS para dados geoespaciais
• Instance: db.t3.micro (development) / db.t3.small (production)
• Storage: 20GB GP2 inicial (auto-scaling habilitado)

Recursos de Segurança:

• Execução dentro de VPC privada
• Backup automático diário
• Multi-AZ para alta disponibilidade (production)

6. AWS Secrets Manager (Gerenciamento de Credenciais)

Função: Armazenamento seguro de informações sensíveis

Itens Gerenciados:

• Credenciais do banco de dados RDS
• Chaves de API de serviços externos
• Tokens JWT secrets
• Configurações sensíveis da aplicação

Vantagens:

• Rotação automática de credenciais
• Controle de acesso via IAM
• Versionamento de secrets
• Auditoria de acesso