ImpressãoMais3D
Comercio electrónico de impresión 3D bajo demanda
Contexto
Una tienda de impresión 3D vende dos cosas muy distintas en el mismo carrito: una pieza de catálogo y una pieza que todavía no existe, enviada por el cliente como archivo 3D. Ambas pasan por presupuesto, producción, entrega o recogida en tienda.
El desafío
Vender una pieza que nadie ha visto todavía. El cliente debe confiar en el resultado antes de iniciar la producción y, una vez impresa, no hay vuelta atrás. Si a esto se suma un pedido que atraviesa presupuesto, diseño, pago, producción y entrega, cada etapa con sus propias reglas, el verdadero riesgo deja de ser técnico y pasa a ser comercial: imprimir la pieza equivocada cuesta material y tiempo.
La arquitectura
Una prueba visual 3D generada automáticamente a partir del archivo enviado y renderizada en el navegador, que el cliente aprueba antes de que nada llegue a la impresora: la aprobación es un requisito explícito del proceso, no un aviso. Por debajo, un monolito modular con veinte contextos delimitados cuyos límites se hacen cumplir mediante herramientas, no por convención.
Cómo se organiza el código
Monolito modular organizado por contextos delimitados en src/modules/, con veinte contextos, entre ellos catálogo, precios, carrito, pedidos, pagos, diseños, prueba visual, preparación de pedidos, cupones, campañas, CRM y base de conocimiento de IA.
Flujo de la arquitectura
Pedido
- Pieza de catálogo
- Archivo STL, OBJ o 3MF
Prueba visual 3D
- Generada a partir del archivo enviado
- React Three Fiber
Aprobación del cliente
- Requisito explícito del proceso
- Registro auditable
Producción
- Bloqueada hasta la aprobación
- FDM, resina y SLS
Entrega
- Envío o recogida en tienda
Decisiones de ingeniería
Prueba visual antes de producir
El archivo enviado (STL, OBJ o 3MF) se renderiza en el navegador con React Three Fiber y se convierte en una prueba que el cliente aprueba o rechaza. La producción queda bloqueada hasta su aprobación, convirtiendo una conversación sobre expectativas en un registro auditable.
Límites que el linter hace cumplir
Cada módulo tiene capas de dominio, aplicación, infraestructura y presentación. La capa de dominio no importa Supabase, Next ni React: lo garantiza una regla de ESLint (no-restricted-imports), no la disciplina del equipo. Los módulos solo se comunican a través de la capa de aplicación.
La autorización reside en la base de datos
Los permisos son políticas de seguridad a nivel de fila (Row Level Security) en Postgres, no comprobaciones dispersas por la interfaz. La pantalla puede equivocarse; la fila de la base de datos sigue protegida.
Renunciar a la complejidad de forma deliberada
Sin microservicios, bus de eventos ni colas, y esa decisión está documentada en la arquitectura junto con sus motivos. Saber cuándo no distribuir es una decisión de diseño tan real como saber cómo hacerlo.
Pruebas en los puntos críticos
Vitest para las reglas de negocio y una suite de Playwright que cubre los flujos de dinero y producción: pagos, prueba visual, diseños, preparación de pedidos y panel de distribuidores.