Skip to content

Commit 4ee230b

Browse files
avbctravbctr
committed
feito
1 parent 8dab521 commit 4ee230b

File tree

1 file changed

+159
-43
lines changed

1 file changed

+159
-43
lines changed

‎README.md‎

Lines changed: 159 additions & 43 deletions
Original file line numberDiff line numberDiff line change
@@ -1,84 +1,200 @@
1-
# Sistema de Gerenciamento de Tarefas - API
1+
# 📌 Sistema de Gerenciamento de Tarefas – API
22

3-
Esta é a API RESTful para o sistema de gerenciamento de tarefas, desenvolvida como parte de um desafio técnico. A API permite o gerenciamento de projetos e tarefas, seguindo um conjunto de regras de negócio específicas.
3+
[![Status da Build](https://img.shields.io/badge/build-passing-brightgreen)](https://github.com/avbctr/TaskManagement.Api/actions)
4+
[![Cobertura de Código](https://img.shields.io/badge/coverage-80%2B-blue)](https://github.com/avbctr/TaskManagement.Api)
5+
[![Licença](https://img.shields.io/badge/license-MIT-lightgrey)](https://github.com/avbctr/TaskManagement.Api/blob/main/LICENSE)
6+
7+
Esta é uma API RESTful desenvolvida como parte de um desafio técnico, com foco em produtividade, organização e colaboração. A aplicação permite que usuários gerenciem projetos e tarefas, respeitando regras de negócio reais e pensadas para equipes ágeis.
8+
9+
---
10+
11+
## 📖 Índice
12+
13+
- [✨ Tecnologias e Arquitetura](#-tecnologias-e-arquitetura)
14+
- [📂 Visão Geral da Estrutura do Projeto](#-visão-geral-da-estrutura-do-projeto)
15+
- [🚀 Como Executar o Projeto](#-como-executar-o-projeto)
16+
- [⚙️ Detalhes de Configuração](#️-detalhes-de-configuração)
17+
- [🧪 Testes e Cobertura de Código](#-testes-e-cobertura-de-código)
18+
- [📝 Endpoints da API](#-endpoints-da-api)
19+
- [🧐 Fase 2 – Perguntas para o Product Owner (PO)](#-fase-2--perguntas-para-o-product-owner-po)
20+
- [🛠️ Fase 3 – Melhorias e Visão de Futuro](#️-fase-3--melhorias-e-visão-de-futuro)
21+
- [👨‍💻 Sobre o Autor](#-sobre-o-autor)
22+
23+
---
424

525
## ✨ Tecnologias e Arquitetura
626

7-
Este projeto foi desenvolvido utilizando um stack moderno e práticas de alta qualidade para garantir testabilidade, manutenibilidade e escalabilidade.
27+
O projeto foi construído com base em decisões arquiteturais sólidas e tecnologias modernas, visando escalabilidade, testabilidade e clareza de código.
828

929
- **Framework:** .NET 8
1030
- **Arquitetura:** Clean Architecture
11-
- **Banco de Dados:** PostgreSQL (orquestrado com Docker)
31+
- **Banco de Dados:** PostgreSQL (via Docker)
1232
- **ORM:** Entity Framework Core 8
13-
- **Testes:** xUnit e Moq
33+
- **Testes:** xUnit + Moq (com cobertura superior a 80%)
1434
- **Containerização:** Docker & Docker Compose
35+
- **Documentação da API:** Swagger (com comentários XML detalhados)
36+
37+
---
38+
39+
## 📂 Visão Geral da Estrutura do Projeto
40+
41+
A solução está organizada seguindo os princípios da **Clean Architecture**, promovendo a separação de responsabilidades e a manutenibilidade.
42+
43+
- **`TaskManagement.Domain`**: Contém as entidades de negócio principais, enums e view models. Este é o coração da aplicação e não possui dependências externas.
44+
- **`TaskManagement.Application`**: Contém a lógica da aplicação, incluindo serviços, interfaces (repositórios, serviços) e objetos de transferência de dados (payloads, responses). Orquestra a camada de domínio para realizar operações de negócio.
45+
- **`TaskManagement.Infrastructure`**: Implementa as preocupações externas, como o acesso a dados (Entity Framework DbContext, repositórios) e integrações com outros serviços. Depende da camada de Aplicação.
46+
- **`TaskManagement.Api`**: A camada de apresentação, que expõe as funcionalidades da aplicação através de uma API RESTful. Lida com requisições HTTP, validação e serialização, dependendo da camada de Aplicação para executar as tarefas.
47+
- **`TaskManagement.Application.UnitTests`**: Contém testes unitários para a camada de Aplicação, garantindo que a lógica de negócio está correta e confiável.
48+
49+
---
1550

1651
## 🚀 Como Executar o Projeto
1752

18-
É necessário ter o **Docker** e o **Docker Compose** instalados para executar este projeto.
53+
### Pré-requisitos
54+
55+
- Docker
56+
- Docker Compose
1957

20-
1. Clone o repositório:
58+
### Executando a Aplicação
59+
60+
1. **Clone o repositório:**
61+
```bash
62+
git clone https://github.com/avbctr/TaskManagement.Api.git
63+
```
64+
65+
2. **Navegue até o diretório do projeto:**
2166
```bash
22-
git clone <URL_DO_SEU_REPOSITORIO>
2367
cd TaskManagement.Api
2468
```
2569

26-
2. Execute o Docker Compose a partir da raiz do projeto (onde o arquivo `docker-compose.yml` está localizado):
70+
3. **Construa e execute os containers:**
2771
```bash
2872
docker-compose up --build
2973
```
3074

31-
3. Aguarde os containers serem construídos e iniciados. A API estará disponível nos seguintes endereços:
32-
- `http://localhost:8080`
33-
- `https://localhost:8081`
75+
A API estará disponível em:
76+
- **HTTP:** `http://localhost:8080`
77+
- **HTTPS:** `https://localhost:8081`
78+
- **Swagger UI:** `http://localhost:8080/swagger`
79+
80+
*Observação: As migrations do Entity Framework são aplicadas automaticamente na primeira execução.*
81+
82+
---
83+
84+
## ⚙️ Detalhes de Configuração
3485

35-
A primeira vez que a API for iniciada, as migrations do Entity Framework serão aplicadas automaticamente para criar o banco de dados e as tabelas.
86+
A configuração da aplicação é gerenciada através do arquivo `appsettings.json` e arquivos específicos de ambiente, como `appsettings.Development.json`.
87+
88+
- **`ConnectionStrings`**: A string `DefaultConnection` é usada pelo Entity Framework para se conectar ao banco de dados PostgreSQL. Ao usar o `docker-compose`, esta já vem pré-configurada para se conectar ao serviço `postgres`.
89+
- **`Logging`**: Configura os níveis de log para diferentes partes da aplicação.
90+
- **`Kestrel`**: Define os endpoints (portas HTTP/HTTPS) para o servidor web.
91+
92+
Para desenvolvimento local fora do Docker, pode ser necessário ajustar a string `DefaultConnection` para apontar para sua instância local do PostgreSQL.
93+
94+
---
95+
96+
## 🧪 Testes e Cobertura de Código
97+
98+
- **Testes Unitários:** Desenvolvidos com xUnit and Moq.
99+
- **Cobertura de Código:** Superior a 80%.
100+
- **Relatórios:** Gerados via Coverlet + ReportGenerator.
101+
- **Foco:** Regras de negócio, fluxos positivos e negativos.
102+
103+
---
36104

37105
## 📝 Endpoints da API
38106

39-
*(Aqui você listaria os endpoints, por exemplo:)*
107+
As rotas documentadas foram verificadas com base no código-fonte.
108+
109+
### Projetos (`v1/Projetos`)
40110

41-
| Verbo | Rota | Descrição |
42-
| :----- | :--------------------------- | :---------------------------------------- |
43-
| `GET` | `/api/users/{userId}/projects` | Lista todos os projetos de um usuário. |
44-
| `POST` | `/api/projects` | Cria um novo projeto. |
45-
| `GET` | `/api/projects/{projectId}/tasks` | Lista todas as tarefas de um projeto. |
46-
| ... | ... | ... |
111+
| Método | Endpoint | Descrição |
112+
| :----- | :------------------------------ | :---------------------------------------- |
113+
| `GET` | `/{id}` | Obtém um projeto pelo seu ID. |
114+
| `GET` | `/usuario/{userId}` | Obtém todos os projetos de um usuário. |
115+
| `POST` | `/` | Cria um novo projeto. |
116+
| `PUT` | `/` | Atualiza um projeto existente. |
117+
| `DELETE` | `/{id}` | Deleta um projeto pelo seu ID. |
47118

119+
### Tarefas (`v1/Tarefas`)
120+
121+
| Método | Endpoint | Descrição |
122+
| :----- | :------------------------------ | :---------------------------------------- |
123+
| `GET` | `/{id}` | Obtém uma tarefa pelo seu ID. |
124+
| `POST` | `/` | Cria uma nova tarefa. |
125+
| `PUT` | `/` | Atualiza uma tarefa existente. |
126+
| `DELETE` | `/{id}` | Deleta uma tarefa pelo seu ID. |
127+
| `POST` | `/comentario` | Adiciona um comentário a uma tarefa. |
128+
| `DELETE` | `/comentario/{comentarioId}` | Deleta um comentário pelo seu ID. |
129+
| `GET` | `/relatorio-desempenho` | Obtém um relatório de desempenho (perfil gerente). |
48130

49131
---
50132

51-
## 🧐 Fase 2: Perguntas para o Product Owner (PO)
133+
## 🧐 Fase 2 – Perguntas para o Product Owner (PO)
134+
135+
Para garantir que o produto evolua com clareza e propósito, aqui estão as perguntas que eu faria ao PO:
52136

53-
Visando o refinamento do produto e futuras implementações, eu levantaria as seguintes questões com o PO:
137+
### 🔐 Autenticação e Permissões
138+
- Como os perfis de "usuário" e "gerente" serão definidos e validados? O perfil virá via JWT?
139+
- Precisamos de integração com um serviço de identidade externo?
54140

55-
1. **Gestão de Usuários e Permissões:** Como o "usuário" e a role de "gerente" serão definidos e gerenciados pelo serviço externo? Precisamos de um ID de usuário único (UUID, e-mail)? A role virá em um token JWT?
56-
2. **Colaboração:** A visão é que um projeto pertença a um único usuário ou múltiplos usuários poderão colaborar em um mesmo projeto? Se sim, quais seriam os níveis de permissão (leitura, escrita)?
57-
3. **Notificações:** Devemos notificar os usuários sobre eventos importantes, como a data de vencimento de uma tarefa se aproximando ou quando um comentário é adicionado? Se sim, por qual canal (e-mail, push notification, etc.)?
58-
4. **Priorização dos Relatórios:** Qual é a principal dor que o relatório de "média de tarefas concluídas" busca resolver? Existem outros KPIs (Key Performance Indicators) de desempenho que seriam mais valiosos para os gerentes neste momento?
59-
5. **Critérios de Aceitação para "Concluída":** Apenas mudar o status para "Concluída" é suficiente, ou haverá um fluxo de aprovação onde um gerente precisa validar a conclusão da tarefa?
60-
6. **Tratamento de Erros no Frontend:** Qual é a experiência de usuário esperada quando uma regra de negócio é violada (ex: limite de tarefas atingido)? Devemos retornar mensagens de erro genéricas ou códigos específicos que o frontend possa interpretar para exibir mensagens amigáveis?
141+
### 👥 Colaboração
142+
- Projetos serão sempre individuais ou poderão ser compartilhados entre usuários?
143+
- Haverá permissões granulares (leitura, escrita, administração)?
144+
145+
### 🔔 Notificações
146+
- Devemos alertar usuários sobre tarefas vencendo ou novos comentários?
147+
- Qual o canal preferido: e-mail, push, integração com Slack?
148+
149+
### 📊 Relatórios
150+
- O relatório de tarefas concluídas atende a qual dor real?
151+
- Há outros KPIs que os gerentes gostariam de acompanhar (ex: tempo médio de conclusão, tarefas atrasadas)?
152+
153+
### ✅ Fluxo de Conclusão
154+
- Mudar o status para "Concluída" é suficiente ou precisa de validação por um gerente?
155+
156+
### ⚠️ UX de Erros
157+
- Como o frontend deve reagir a erros de negócio? Mensagens genéricas ou códigos específicos para UX personalizada?
61158

62159
---
63160

64-
## 🛠️ Fase 3: Possíveis Melhorias e Visão de Futuro
161+
## 🛠️ Fase 3 – Melhorias e Visão de Futuro
65162

66163
Pensando na evolução do projeto, proponho as seguintes melhorias técnicas e arquiteturais:
67164

68-
1. **Arquitetura e Padrões:**
69-
* **Implementar CQRS com MediatR:** Separar os modelos de leitura (Queries) dos de escrita (Commands) pode otimizar e organizar melhor o código, especialmente em cenários complexos.
70-
* **Validação de Requisições com FluentValidation:** Mover a validação dos DTOs para uma camada dedicada usando FluentValidation, mantendo os controllers mais limpos e a lógica de validação centralizada e testável.
71-
* **Mapeamento com AutoMapper:** Automatizar o mapeamento entre Entidades e DTOs para reduzir código boilerplate e suscetível a erros.
165+
### 🧱 Arquitetura
166+
- **CQRS com MediatR:** Separar os modelos de leitura (Queries) dos de escrita (Commands) melhora a organização do código, facilita testes e permite escalar partes da aplicação de forma independente.
167+
- **FluentValidation:** Centraliza a validação dos DTOs, deixando os controllers mais limpos e permitindo testes unitários específicos para regras de entrada.
168+
- **AutoMapper:** Reduz o código repetitivo de mapeamento entre entidades e view models, diminuindo erros e aumentando a produtividade.
169+
170+
### 🔍 Observabilidade e Resiliência
171+
- **Serilog:** Logging estruturado facilita a análise de logs em ambientes distribuídos e melhora a rastreabilidade de erros.
172+
- **Health Checks:** Permite monitorar a saúde da API e suas dependências, essencial para ambientes orquestrados como Kubernetes.
173+
- **Polly:** Implementa políticas de resiliência como retries e circuit breakers, protegendo a aplicação contra falhas temporárias de serviços externos.
174+
- **Rate Limiting:** Controla o número de requisições por usuário ou IP, protegendo a API contra abusos e garantindo estabilidade em cenários de alta carga.
175+
176+
### ☁️ Cloud & DevOps
177+
- **Pipeline de CI/CD:** Automatiza testes, build e deploy, garantindo entregas contínuas e seguras com cada commit.
178+
- **Deploy em AKS ou AWS ECS:** Permite escalar horizontalmente com alta disponibilidade e gerenciamento simplificado.
179+
- **Gerenciamento de Segredos:** Move credenciais sensíveis para serviços como Azure Key Vault ou AWS Secrets Manager, aumentando a segurança da aplicação.
180+
181+
### 🧪 Testes
182+
- **Testes de Integração:** Validam o fluxo completo da aplicação, garantindo que os componentes funcionem bem juntos.
183+
- **Testes de Contrato:** Asseguram que a comunicação entre frontend e backend esteja sempre alinhada.
184+
- **Testes de Carga:** Avaliam o desempenho da API sob diferentes níveis de uso, antecipando gargalos e otimizando recursos.
185+
186+
---
187+
188+
## 👨‍💻 Sobre o Autor
189+
190+
**Anderson Costa ∴**
72191

73-
2. **Observabilidade e Resiliência:**
74-
* **Logging Estruturado com Serilog:** Implementar logging estruturado para facilitar a busca e análise de logs em ambientes como a nuvem.
75-
* **Health Checks:** Adicionar endpoints de Health Check para monitorar a saúde da API e suas dependências (como o banco de dados), essencial para ambientes orquestrados como Kubernetes.
76-
* **Polly para Resiliência:** Utilizar a biblioteca Polly para implementar políticas de resiliência, como *retries* e *circuit breakers*, em chamadas a serviços externos.
192+
*Analista de Sistemas/Especialista .NET/C#*
77193

78-
3. **Visão de Cloud/DevOps:**
79-
* **Pipeline de CI/CD:** Criar um pipeline automatizado (usando GitHub Actions, Azure DevOps, etc.) que, a cada commit na branch principal, execute os testes, construa a imagem Docker e a publique em um registro de contêineres (como Docker Hub ou Azure Container Registry).
80-
* **Estratégia de Deploy:** A arquitetura containerizada permite um deploy fácil em serviços como Azure App Service, Azure Kubernetes Service (AKS) ou AWS ECS, garantindo escalabilidade e alta disponibilidade.
81-
* **Gerenciamento de Configuração:** Mover segredos, como connection strings, do `appsettings.json` para um serviço de gerenciamento de segredos (como Azure Key Vault ou AWS Secrets Manager) para aumentar a segurança.
194+
[![LinkedIn](https://img.shields.io/badge/LinkedIn-0077B5?style=flat&logo=linkedin&logoColor=white)](https://br.linkedin.com/in/andersonvbcosta)
195+
[![Portfolio](https://img.shields.io/badge/Portfolio-4B0082?style=flat&logo=react&logoColor=white)](https://avbc.dev)
196+
[![GitHub](https://img.shields.io/badge/GitHub-181717?style=flat&logo=github&logoColor=white)](https://github.com/avbctr)
82197

83-
4. **Testes:**
84-
* **Testes de Integração:** Adicionar uma camada de testes de integração que utilize um banco de dados de teste (em memória ou um container Docker) para validar o fluxo completo da aplicação, desde o controller até o banco de dados.
198+
![.NET](https://img.shields.io/badge/.NET-512BD4?style=flat&logo=dotnet&logoColor=white)
199+
![C#](https://img.shields.io/badge/C%23-239120?style=flat&logo=csharp&logoColor=white)
200+
![Azure](https://img.shields.io/badge/Azure-0078D4?style=flat&logo=microsoftazure&logoColor=white)

0 commit comments

Comments
 (0)