Backend Java, Spring y APIs internas

Contexto

He trabajado en aplicaciones internas y piezas de integración donde el consumidor es otro servicio o proceso del mismo entorno. Ahí el trabajo real pasa por definir contratos HTTP que otros equipos puedan usar sin adivinar, implementar servicios con reglas de negocio coherentes y sostener persistencia transaccional cuando el dato tiene que cuadrar con el dominio. El stack es el mismo ecosistema que en proyectos públicos como Fat & Happy POS o Multilingual Support, pero el alcance aquí es laboral: sin publicar código interno.

Problema

Acoplamiento entre capas hace que un cambio en datos o en reglas rompa a quien consume el servicio sin aviso. Los errores poco claros (códigos genéricos, mensajes vacíos, información de depuración mal acotada) obligan a quien integra a perder tiempo. La deuda técnica crece cuando no se define bien el acuerdo entre sistemas, la validación en la entrada y una mínima trazabilidad de qué falló y por qué: bajo presión, “que compile y pase” deja huecos que luego pagan otros módulos o el propio equipo.

Qué resolvía el sistema o proyecto

Rutas de servicio y flujos que otros equipos pueden usar con expectativas claras: qué enviar, qué recibir y qué significa cada error. La capa de servicio concentra las reglas de negocio; los datos se guardan de forma coherente con esas reglas; la validación y los mensajes de error reducen idas y vueltas. No se trataba de un producto público, sino de un backend usable y mantenible por quien depende de él.

Mi rol

Diseño de rutas y acuerdos de datos (qué expone cada servicio y qué queda fuera), lógica de negocio y criterio sobre dónde termina cada responsabilidad. Validación y errores en la entrada para no propagar datos inválidos ni respuestas incomprensibles. Persistencia con JPA/Hibernate cuando encaja el modelo, y SQL o acceso directo cuando el caso lo pide. Pruebas (JUnit) donde más se mueve el acuerdo entre sistemas o la regla de negocio. Mantenimiento y legibilidad: cambios incrementales, nombres y estructura que otra persona del equipo pueda seguir, y apoyo en despliegues cuando el cambio toca datos o interfaces.

Stack

Java como base; Kotlin en módulos donde el contexto del proyecto ya lo usa (no asumo Kotlin en todos los entornos). Spring Boot para servicios y configuración; Hibernate / JPA para gran parte del acceso relacional; JUnit para regresión de comportamiento. Compilación con Maven o Gradle según el proyecto. SQL y otros accesos a datos cuando la consulta o el rendimiento no encajan en un único camino ORM. Git para historial y revisión; JavaScript solo de forma puntual en clientes ligeros o scripts auxiliares.

Decisiones importantes

• Acuerdos claros entre capas: modelos de datos explícitos frente a exponer directamente tablas o entidades internas.
• Errores comprensibles: códigos y mensajes que el cliente pueda actuar sin adivinar el estado interno.
• Separación por capas: entrada HTTP, dominio/servicio y persistencia distinguibles para poder testear y cambiar con menos efectos colaterales.
• Pruebas donde aportan: regresión en puntos que cambian a menudo (interfaces entre sistemas, reglas críticas), sin perseguir cobertura vacía.
• Evitar acoplamientos innecesarios: evolución cuidadosa de servicios internos cuando hay más de un consumidor; dependencias acotadas entre módulos.

Restricciones o NDA

Sin código del empleador, sin métricas internas ni fragmentos identificables.

Resultado o aprendizaje

Lo que buscaba demostrar con este caso es que sé moverme entre servicios, datos y mantenimiento en un backend que otros consumen: no solo escribir clases, sino dejar un servicio que se pueda integrar y evolucionar. El valor es de perfil backend práctico, anclado en trabajo real; los proyectos públicos del portfolio sirven como contraste revisable con código abierto.