El contexto: no era solo crear endpoints
QualityTrack es una plataforma para el seguimiento de trabajos de mecanizado industrial, desarrollada durante una simulación profesional de NoCountry. El equipo dejó la base inicial; después asumí la implementación de los flujos comerciales y operativos restantes, su integración y la entrega final.
Un pedido podía avanzar por solicitud, cotización, orden de trabajo, producción, control de calidad y entrega. Mi desafío era que cada paso tuviera reglas verificables y que el expediente pudiera explicar qué pasó y por qué. No era suficiente tener un CRUD independiente para cada módulo.
1. Cotizaciones: conservar el historial de una negociación
Problema. Una propuesta enviada al cliente puede recibir una solicitud de ajuste. Si se sobrescribe la misma fila sin modelar el proceso, se pierde el contexto de lo que se ofreció y de lo que el cliente pidió cambiar.
Decisión. En el backend separé el flujo en operaciones de crear, editar, enviar, aprobar, rechazar, solicitar ajuste y crear revisión. QuotationWorkflowService trabaja con estados, permisos y transacciones; la solicitud de ajuste conserva sus notas y abre una nueva revisión en borrador.
La regla no depende de ocultar botones en React: el servicio valida el estado de la cotización y el actor antes de aplicar la operación. Los cambios relevantes se registran con TraceabilityService. La revisión comercial también puede almacenar una respuesta al ajuste antes de volver a enviarse.
Evidencia. El PR #39 incorpora QuotationWorkflowService y sus pruebas. Entre los casos comprobados están customerAdjustmentSupersedesSentRevisionAndCreatesNextDraft, aprobación con evento de trazabilidad y el rechazo de cancelar un borrador de ajuste sin la respuesta comercial requerida. Son pruebas del comportamiento del servicio, no una medición de uso real.
2. Calidad: un resultado fallido debe cambiar el proceso
Problema. Una inspección no puede limitarse a guardar una lista de mediciones. Si falla un control, producción no debería avanzar silenciosamente a entrega.
Decisión. QualityWorkflowService completa la inspección dentro de una transacción. Cuando los controles cumplen, la inspección se aprueba y la orden puede pasar a READY_FOR_DELIVERY. Si falla un control, la orden pasa a QUALITY_HOLD y puede crearse una NonConformity. El flujo contempla disposiciones como REWORK, SCRAP y USE_AS_IS; esta última requiere autorización administrativa.
El retrabajo conserva su relación con la no conformidad original. Tras volver a producción se genera una reinspección: si aprueba, puede cerrar esa no conformidad; si vuelve a fallar, permanece abierta. En la integración posterior también amplié los controles para admitir distintos tipos de verificación.
Evidencia. El PR #47 incluye servicios, migraciones V22 y V23 y pruebas. QualityWorkflowServiceTest contiene escenarios concretos: allPassingChecksApproveInspectionAndOrder, failingCheckRejectsInspectionAndOpensNonConformity, approvedReinspectionClosesOriginalNonConformity y failedReinspectionKeepsSameNonConformityOpen.
3. Expediente 360: explicar una orden sin reconstruirla a mano
Problema. Las cotizaciones, hojas de ruta, consumos, documentos, inspecciones y entregas viven en módulos distintos. Para alguien que revisa una orden, mostrar solo su estado actual no responde qué ocurrió en el camino.
Decisión. WorkOrder360Service compone una respuesta con esos recursos y una línea de eventos. Cada evento puede incluir un snapshot del cambio y acciones navegables, resueltas por TraceabilityActionResolver, hacia la entidad relacionada. Esto permite ver, por ejemplo, qué versión de documento correspondía a un evento.
El PR #53 también agrupó lecturas de versiones de documentos y lotes para reducir consultas repetidas de tipo N+1. No atribuyo un porcentaje de mejora: no tengo un benchmark publicado que lo demuestre.
Evidencia. WorkOrder360ServiceTest comprueba la composición, lecturas por lote, snapshot y resolución de una acción VIEW_DOCUMENT_VERSION. Es una prueba con dependencias simuladas; demuestra la composición del servicio, no el rendimiento de PostgreSQL bajo carga.
Qué validé y qué no puedo prometer
Los PRs #39, #47 y #53 incluyen pruebas JUnit de reglas y composición; el PR #39 también incorpora una prueba de repositorio. El PR #55 reúne la integración final y los ajustes de la demo. Los archivos y las descripciones de esos PRs están enlazados para poder revisarlos.
Esto no equivale a haber probado tráfico de producción, alta disponibilidad ni un porcentaje global de cobertura. QualityTrack es una simulación funcional, no un producto con métricas de clientes reales.
Hay además una deuda que identifiqué al releer el código: TraceabilityService ofrece una consulta de timeline paginada, pero el Expediente 360 utiliza timelineAll para componer el historial completo. En expedientes extensos, revisaría esa carga antes de afirmar que la vista escala sin problemas.
Lo que me llevé del proyecto
Elegí mantener el flujo transaccional dentro de una aplicación Spring Boot con módulos por dominio. Separarlo prematuramente en microservicios habría añadido coordinación entre servicios para reglas que necesitaban consistencia.
La lección más útil fue tratar los estados como reglas de negocio, no como etiquetas de interfaz: una cotización revisada, una orden retenida por calidad y una reinspección aprobada deben poder explicarse desde el backend y sus pruebas.
Mi siguiente mejora técnica sería probar el recorrido completo con una base PostgreSQL real y datos de una orden con muchas revisiones y eventos, además de paginar o acotar la composición del 360. Ya existe una demo; esta sería la forma de respaldar mejor sus garantías.