arquitetura.md

@@ -111,3 +111,65 @@ A arquitetura foi escolhida para:
 - 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
+
+![image](uploads/e3cf9d32899afc8a4472947d551ac219/image.png)
+
+
+---
+
+## 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.
\ No newline at end of file