ImpressãoMais3D
E-commerce de impressão 3D sob demanda
Contexto
Uma loja de impressão 3D vende duas coisas muito diferentes pelo mesmo carrinho: uma peça pronta de catálogo e uma peça que ainda não existe, enviada pelo cliente como arquivo 3D. As duas atravessam orçamento, produção, entrega e retirada na loja.
O desafio
Vender uma peça que ninguém viu ainda. O cliente precisa confiar no resultado antes de a produção começar — e, uma vez impressa, não há como desfazer. Some a isso um pedido que atravessa orçamento, arte, pagamento, produção e entrega, cada etapa com regra própria, e o risco real deixa de ser técnico e passa a ser de negócio: imprimir a coisa errada custa material e tempo.
A arquitetura
Uma prova visual 3D gerada automaticamente a partir do arquivo enviado, renderizada no navegador, que o cliente aprova antes de qualquer coisa ir para a impressora — a aprovação é um portão explícito no fluxo, não um aviso. Por baixo, um monólito modular com vinte bounded contexts, em que a fronteira entre módulos é verificada por ferramenta, não por combinado.
Organização do código
Monólito modular organizado por bounded context em src/modules/, com vinte contextos — entre eles catálogo, precificação, carrinho, pedido, pagamento, arte, prova visual, expedição, cupom, campanha, CRM e base de conhecimento da IA.
Decisões de engenharia
Prova visual antes da produção
O arquivo enviado (STL, OBJ ou 3MF) é renderizado no navegador com React Three Fiber e vira uma prova que o cliente aprova ou rejeita. A produção fica travada até a aprovação — o que transforma uma discussão sobre expectativa em um registro auditável.
Fronteiras que o linter cobra
Cada módulo tem as camadas domain / application / infrastructure / presentation, e a camada de domínio não importa Supabase, Next ou React — isso é imposto por regra de ESLint (no-restricted-imports), não por disciplina. Módulos só se falam pela camada de aplicação.
Autorização mora no banco
As permissões são políticas de Row Level Security no Postgres, não checagens espalhadas pela interface. A tela pode errar; a linha do banco continua protegida.
Recusa deliberada de complexidade
Sem microserviços, sem event bus, sem filas — e isso está escrito na arquitetura, com a justificativa. Saber quando não distribuir é uma decisão de projeto tão real quanto saber distribuir.
Testado onde dói
Vitest nas regras de negócio e uma suíte Playwright que cobre os fluxos de dinheiro e de produção: pagamento, prova visual, arte, expedição e o painel do revendedor.