Trackrr

A aplicação segue Routes → Controllers → Services → Repositories, com cada camada possuindo uma única responsabilidade. Controllers não acessam o Prisma, services não manipulam req/res, e repositories não contêm regras de negócio. Dependências fluem em uma única direção.

Repositories podem ser mockados para testar services em isolamento; o Prisma client pode ser mockado para testar rotas end-to-end. Regras de negócio ficam nos services, validações nos schemas, e mudanças de persistência não vazam para o restante do sistema.

Todos os campos monetários usam Decimal(12,2) no Prisma e são serializados como string no JSON (“12.50” em vez de 12.5). Evita problemas de precisão do IEEE 754 — 0.1 + 0.2 === 0.30000000000000004 em JavaScript — que acumulam erros em operações sobre orçamento.

Serializar como string preserva a precisão até o consumidor, que pode optar pela representação adequada ao seu contexto (libs como decimal.js no front-end, BigInt para cálculos exatos, ou conversão para float quando precisão não é crítica).

A suíte (Vitest + Supertest) executa 79 testes em ~1 segundo sem dependência de banco em execução. O Prisma client é mockado via vi.mock, e cada teste configura explicitamente o comportamento dos métodos consumidos. Cobertura inclui rotas, middlewares, services, mappers — toda a stack acima da camada de persistência.

Trade-off: bugs de SQL ou migrations quebradas não são detectados aqui. A camada complementar seria testes de repository contra Postgres real (testcontainers) no pipeline de CI.

Estado de UI e estado de servidor são tratados por ferramentas distintas. Server state usa TanStack Query — cache, invalidação, refetch e dedup de requests em flight.

Zustand entra só onde Query não cabe: o par { token, user } da auth, que precisa ser síncrono, persistir em localStorage e ser lido fora de componente (interceptor do Axios). Server state e client state ficam em camadas distintas.

features/expenses/ agrupa tudo da feature: api.ts, hooks.ts, schemas.ts, types.ts, components/. A pasta app/ fica fina — cada página é composição desses hooks e components.

Regra: features não importam umas das outras. Qualquer coisa transversal vai para shared/. O blast radius de qualquer mudança fica contido na pasta da feature.

Caminho mais fácil seria adicionar Puppeteer/Playwright na API Express e renderizar PDF no back — pixel-perfect, qualquer CSS funciona, mas o custo seria muito alto.

@react-pdf/renderer no client: componentes JSX viram PDF binário direto no navegador, sem rasterizar DOM (que é o que html2canvas faz, e fica pixelado). API fica desacoplada do formato — se amanhã precisar exportar para Excel ou Markdown, é só adicionar outro módulo em features/export/, sem mexer no back.