Por qué nació el proyecto

La aplicación debía gestionar varios tipos de solicitud con reglas, tareas, estados, permisos y relaciones diferentes. Mantener un módulo aislado por cada tipo habría duplicado lógica y contratos.

El problema de diseño

Había que compartir comportamiento sin borrar las diferencias de cada solicitud. Además, una actualización podía afectar a la solicitud principal, sus tareas y colecciones hijas, por lo que la consistencia transaccional era esencial.

Decisiones tomadas

  • Crear un modelo de dominio común con especializaciones por tipo.
  • Exponer endpoints específicos sobre contratos coherentes.
  • Utilizar transacciones para actualizar agregado y relaciones.
  • Aplicar soft-delete y relaciones N-N donde era necesario conservar trazabilidad.
  • Construir formularios Angular dependientes del tipo, el estado y los permisos.

Desarrollo paso a paso

Primero se identificaron invariantes compartidos. Después se separaron las reglas específicas, se definieron relaciones y tareas obligatorias, se implementaron servicios transaccionales y finalmente se conectó el frontend con validación y control de permisos.

Resultado y aprendizaje

La estructura permitió añadir comportamiento sin multiplicar módulos inconexos. La principal lección fue que la herencia técnica no debe sustituir al modelado explícito del dominio.