Skip to content

checklist-entrega.md

Latest commit

 

History

History
71 lines (61 loc) · 4.28 KB

checklist-entrega.md

File metadata and controls

71 lines (61 loc) · 4.28 KB
Raw

Checklist da Entrega Academica

Este checklist reflete o estado real do repositorio nesta fase. A classificacao diferencia:

  • Atendido: requisito implementado ou documentado diretamente no projeto.
  • Atendido com justificativa: requisito demonstrado com limite tecnico assumido e defendido na documentacao.
  • Pendente: ainda nao existe nesta versao ou depende de evolucao futura.

Atendido

  • Descricao do problema escolhido.
  • Proposta de solucao do Trackio.
  • API REST para o modulo de tarefas.
  • Frontend estatico funcional para tarefas reais.
  • Dados de demonstracao documentados em docs/dados-demo.md.
  • DTOs de request/response.
  • Validacao de entrada.
  • Tratamento global de excecoes.
  • Swagger/OpenAPI.
  • Repository Pattern.
  • Adapter Pattern.
  • Mapper Pattern.
  • Factory Pattern.
  • Facade/Service Pattern.
  • DTO Pattern.
  • Dependency Injection.
  • Testes unitarios de dominio, factory, use cases e service.
  • Teste de repository JPA.
  • Testes de controller/API HTTP com MockMvc.
  • Cenarios BDD com Cucumber.
  • Suite automatizada com 55 testes verdes.
  • Dockerfile.
  • Docker Compose com API e PostgreSQL.
  • Volume persistente para PostgreSQL.
  • Profiles dev, test, docker e prod.
  • .env.example para execucao local com Docker.
  • Documentacao academica em docs/.
  • Deploy publico realizado na Railway.
  • Link de acesso publicado: https://taskmanagerapi-production-b8b0.up.railway.app/.
  • Endpoints publicados validados: /, /api/tasks, /api/tasks/dashboard, /api/tasks/kanban, /swagger-ui.html, /v3/api-docs.
  • Relatorio de deploy documentado em docs/relatorio-fase-deploy.md.

Atendido com justificativa

  • Arquitetura Limpa: o projeto e um monolito modular com camadas domain, application, infrastructure e presentation. A application nao usa mais Page/Pageable do Spring Data; usa PageQuery/PageResult proprios. O uso de @Service/@Transactional foi mantido por pragmatismo do Spring e esta documentado em docs/arquitetura.md.
  • SOLID: SRP aparece na separacao controller/DTO/use case/adapter/mapper/handler; DIP aparece na porta TaskRepository; ISP aparece nos use cases pequenos; DI e usada por construtor. Limitacoes e evolucoes estao documentadas em docs/solid.md.
  • TDD: o backend possui 55 testes automatizados e as refatoracoes principais foram feitas protegidas por testes. O projeto nao promete um historico completo de todos os ciclos red/green/refactor, mas documenta o fluxo de teste/refatoracao usado em docs/tdd.md.
  • Clean Code: ha nomes claros, DTOs, use cases, mapper, exception handler, validacoes e separacao de responsabilidades. O dominio simples fica como evolucao futura, documentada em docs/clean-code.md.
  • Microsservicos: nao existem microsservicos executaveis nesta versao. O requisito e defendido por modelagem de bounded contexts, decisao de monolito modular e plano de extracao progressiva em docs/microsservicos.md.
  • Dados demo / empresa ficticia: a empresa Atlas Solucoes Empresariais, seus setores, responsaveis e projetos sao ficticios e servem apenas para demonstracao. Origem e reset estao em docs/dados-demo.md.
  • Docker: atende ao ambiente local com PostgreSQL e volume persistente. A evolucao natural e adicionar migrations com Flyway ou Liquibase.

Pendente

  • Flyway ou Liquibase para migrations.
  • Configuracao segura de credenciais fora do ambiente local.
  • Testes automatizados do frontend.
  • Autenticacao.
  • Organizacao/empresa real como modulo cadastral.
  • Funcionarios/membros como modulo cadastral.
  • Equipes/departamentos como modulo cadastral.
  • Projetos como modulo proprio.
  • Comentarios, anexos e historico.
  • Microsservicos executaveis separados, somente se a avaliacao exigir evidencia pratica alem da proposta arquitetural.

Proximos passos

  1. Apresentar a URL publica da Railway durante a entrega.
  2. Validar novamente /, /api/tasks, /api/tasks/dashboard, /api/tasks/kanban, /swagger-ui.html e /v3/api-docs antes da demonstracao.
  3. Avaliar se a banca exige microsservicos executaveis ou se a proposta arquitetural documentada e suficiente.
  4. Planejar migrations com Flyway ou Liquibase.