Pular para conteúdo

MVP 1 - Transacoes - Tecnico

Topologia

REST

Rotas principais:

  • POST /transactions
  • PUT /transactions/{id}
  • DELETE /transactions/{id}
  • GET /transactions/summary
  • GET /transactions/dashboard
  • GET /transactions/list
  • GET /transactions/expenses
  • GET /transactions/due-range
  • GET /transactions/deleted
  • PATCH /transactions/restore/{id}
  • DELETE /transactions/{id}/force

Arquivo de registro:

  • /tmp/auraxis-platform-mvp1docs-p5AMyw/repos/auraxis-api/app/controllers/transaction/routes.py

GraphQL

Tambem ha queries e mutations para transacoes no backend.

Arquivos-base:

  • /tmp/auraxis-platform-mvp1docs-p5AMyw/repos/auraxis-api/app/graphql/queries/transaction.py
  • /tmp/auraxis-platform-mvp1docs-p5AMyw/repos/auraxis-api/app/graphql/mutations/transaction.py

Modelo de dominio

Arquivos:

  • /tmp/auraxis-platform-mvp1docs-p5AMyw/repos/auraxis-api/app/models/transaction.py
  • /tmp/auraxis-platform-mvp1docs-p5AMyw/repos/auraxis-api/app/schemas/transaction_schema.py

Campos relevantes:

  • title
  • description
  • observation
  • amount
  • currency
  • type
  • status
  • due_date
  • start_date
  • end_date
  • is_recurring
  • is_installment
  • installment_count
  • installment_group_id
  • tag_id
  • account_id
  • credit_card_id
  • paid_at
  • deleted

Orquestracao de regra

Application service:

  • /tmp/auraxis-platform-mvp1docs-p5AMyw/repos/auraxis-api/app/application/services/transaction_application_service.py

Pontos fortes da implementacao:

  • normalizacao de tipo, status, moeda e datas
  • validacao de payload recorrente
  • validacao de ownership de referencias
  • geracao de parcelas em lote
  • soft delete com restauracao

Recursos de leitura

Arquivo:

  • /tmp/auraxis-platform-mvp1docs-p5AMyw/repos/auraxis-api/app/controllers/transaction/report_resources.py

Leituras relevantes:

  • resumo mensal
  • dashboard mensal
  • despesas por periodo
  • vencimentos por periodo
  • lista de ativas
  • lista de deletadas

Pontos arquiteturais relevantes

  • o controller virou fachada de compatibilidade
  • criacao, update e delete foram extraidos em mixins/arquivos dedicados
  • leitura pesada esta em report_resources.py
  • payloads novos tentam conviver com payload legado via contrato de compatibilidade

Drift atual com frontends

  1. frontends consultam GET /dashboard/overview, mas o backend exposto aqui oferece GET /transactions/dashboard
  2. o dashboard de frontend hoje usa fallback visual quando a chamada falha

Riscos tecnicos

  • alto peso funcional em transaction_application_service.py
  • frontends ainda nao usam plenamente os endpoints reais de transacoes
  • a experiencia completa de CRUD ainda nao esta refletida em web/app