Puedes tirar el código. No tires el negocio.

Hay una idea que aparece con frecuencia cuando hablamos de modernizar software:

si una aplicación funciona, hay que conservarla y mejorarla poco a poco.

Muchas veces es cierto.

Pero no siempre.

Hay sistemas que pueden evolucionar mediante refactoring, modularización o sustitución progresiva de componentes.

Y hay otros en los que la arquitectura, el acoplamiento, las dependencias o la antigüedad tecnológica han llegado a un punto en el que conservar el código deja de ser una ventaja.

Eso no significa que todo lo que contiene la aplicación deba desaparecer con él.

Porque después de años funcionando una aplicación suele contener algo mucho más valioso que su framework, sus controladores o sus tablas:

• validaciones;
• estados;
• restricciones;
• cálculos;
• permisos;
• excepciones;
• casos límite;
• comportamientos que los usuarios ya consideran parte natural del negocio.

Ese conocimiento puede seguir siendo válido aunque el código que lo implementa haya dejado de serlo.

Y ahí aparece la pregunta que está guiando buena parte de Alixar-Solúcar:

¿Podemos sustituir completamente una implementación legacy sin perder las reglas de negocio que la empresa sí necesita conservar?

Creo que sí.

Pero para hacerlo hay que dejar de confundir dos cosas distintas:

el código que tenemos y el negocio que ese código representa.

Una aplicación legacy es una implementación histórica del negocio. No es el negocio.

Reescribir no debería significar traducir

Una forma peligrosa de abordar una reescritura consiste en cambiar de tecnología manteniendo intacta la estructura mental de la aplicación anterior.

Por ejemplo:

• PHP pasa a Java;
• una pantalla antigua pasa a Angular;
• una consulta SQL se convierte en otra consulta SQL;
• una clase enorme se divide en varias clases nuevas.

Pero después del cambio:

• las mismas responsabilidades siguen mezcladas;
• los mismos acoplamientos continúan existiendo;
• las mismas decisiones accidentales reaparecen con nombres nuevos.

El resultado puede ser técnicamente moderno y arquitectónicamente viejo.

Traducir un legacy a una tecnología actual puede producir simplemente un legacy nuevo.

Por eso la primera operación no debería ser traducir.

Debería ser extraer conocimiento.

El proceso que me interesa es otro:

1. observar el comportamiento existente;
2. identificar qué reglas expresa;
3. distinguir una regla de negocio de una limitación técnica histórica;
4. comprobar si esa regla sigue siendo válida;
5. caracterizarla mediante pruebas y ejemplos;
6. incorporarla al nuevo modelo de dominio;
7. implementarla con límites más claros.

El código antiguo puede ayudarnos a descubrir la regla.

Pero no tiene por qué dictar cómo debemos implementarla de nuevo.

No todo legacy necesita la misma estrategia

No existe una única respuesta correcta para modernizar software.

Hay aplicaciones que pueden mejorar durante años mediante refactoring continuo.

Otras pueden separar progresivamente responsabilidades hasta convertirse en sistemas más modulares.

Y existen estrategias conocidas como Strangler Fig Pattern, donde una nueva solución va rodeando al sistema anterior y absorbiendo progresivamente sus capacidades.

Todas ellas pueden ser válidas.

Pero también existe otro escenario.

El sistema actual puede seguir siendo útil como fuente de conocimiento y comportamiento, mientras dejamos de considerarlo la arquitectura sobre la que queremos construir el futuro.

Eso es especialmente importante en Alixar-Solúcar.

El objetivo no es convertir Dolibarr poco a poco en otra cosa.

El objetivo es construir una arquitectura nueva que pueda asumir progresivamente las responsabilidades que hoy resuelve el sistema anterior.

Reescritura completa del destino, migración incremental del camino

Una reescritura completa no obliga necesariamente a realizar una sustitución big bang.

Podemos tener un destino arquitectónico completamente nuevo y, al mismo tiempo, llegar a él por pasos pequeños y verificables.

Reescritura completa del destino. Migración incremental del camino.

El sistema anterior no desaparece el primer día.

Durante un tiempo pueden convivir dos mundos:

• algunas capacidades siguen teniendo su autoridad en Dolibarr;
• otras ya han sido caracterizadas, reconstruidas y asumidas por Alixar;
• Solúcar consume progresivamente los nuevos contratos;
• la proporción cambia con el tiempo hasta que el legacy deja de ser necesario como aplicación operativa.

Migrar una funcionalidad también significa mover la autoridad sobre sus datos

Aquí aparece una cuestión crítica.

Si trasladamos, por ejemplo, la gestión de terceros desde Dolibarr a Alixar, no basta con reconstruir la pantalla o la API.

También hay que decidir:

¿qué sistema es ahora la autoridad sobre esos datos?

Durante una transición pueden existir dos bases de datos distintas.

Eso no es un problema por sí mismo.

Dolibarr puede seguir utilizando MariaDB y Alixar puede utilizar PostgreSQL.

Lo importante es evitar que ambos se conviertan en maestros equivalentes del mismo dato.

La regla es sencilla:

pueden convivir dos sistemas, pero debería existir una única autoridad de escritura para cada capacidad.

Fase inicial

Mientras Dolibarr siga siendo la autoridad sobre terceros:

• Dolibarr/MariaDB mantiene lectura y escritura;
• Alixar puede recibir una copia o proyección;
• Alixar no debería modificar el mismo dato de forma independiente;
• la correspondencia entre identificadores debe mantenerse explícita.

Migración

Cuando esa capacidad esté preparada para cambiar de sistema:

1. se extraen los datos desde MariaDB;
2. se transforman al modelo propio de Alixar;
3. se conserva la relación entre identificadores legacy y nuevos;
4. se cargan en PostgreSQL;
5. se validan registros, relaciones y reglas;
6. se sincronizan los cambios producidos durante la transición;
7. se realiza el cambio de autoridad.

Después del cambio, Alixar/PostgreSQL pasa a ser la autoridad.

Dolibarr puede seguir necesitando temporalmente esos datos si aún existen módulos legacy activos.

En ese caso puede recibirlos mediante una capa de compatibilidad o sincronización controlada.

Pero el sentido de la autoridad ya ha cambiado:

ANTES

Dolibarr / MariaDB
Terceros = READ + WRITE

Alixar / PostgreSQL
Terceros = COPY / READ

DESPUÉS

Alixar / PostgreSQL
Terceros = READ + WRITE

Dolibarr / MariaDB
Terceros = COMPATIBILIDAD TEMPORAL

No se trata de mantener dos maestros.

Se trata de trasladar conscientemente la responsabilidad.

No migramos tablas. Migramos capacidades

Ésta es una diferencia importante.

Una migración bien planteada no consiste simplemente en copiar:

llx_societe -> companies

y dar el trabajo por terminado.

Lo que realmente se traslada es un conjunto:

CAPACIDAD
    +
REGLAS DE NEGOCIO
    +
AUTORIDAD SOBRE EL DATO

La estructura física puede cambiar.

También pueden cambiar:

• nombres;
• claves;
• relaciones;
• normalización;
• tipos de datos;
• restricciones;
• forma de exponer la información.

Alixar no necesita reproducir internamente el modelo de Dolibarr.

Necesita representar correctamente el negocio que decide conservar.

El legacy sigue siendo útil

Decidir no conservar una arquitectura no significa despreciar el sistema anterior.

Puede convertirse en una fuente muy valiosa para preguntar:

• ¿qué ocurre cuando un dato es inválido?
• ¿qué permisos necesita realmente una operación?
• ¿qué estados puede atravesar una entidad?
• ¿qué combinaciones impide el sistema?
• ¿qué cálculos realizan los usuarios sin darse cuenta?
• ¿qué excepciones se han incorporado con los años?
• ¿qué comportamiento esperan otras partes de la organización?

En ese sentido, el legacy puede funcionar como una especificación ejecutable imperfecta.

No porque todo lo que haga sea correcto.

Sino porque nos permite observar qué hace realmente y decidir qué queremos conservar.

La nueva plataforma debe poder vivir sin el legacy

Éste es uno de los criterios más importantes para Alixar-Solúcar.

Si construimos un backend nuevo pero sus reglas continúan dependiendo estructuralmente del código, las tablas o las decisiones internas de Dolibarr, no hemos creado una nueva arquitectura.

Hemos creado otra capa encima.

Por eso el destino necesita tener:

• modelo de dominio propio;
• persistencia propia;
• contratos API propios;
• autenticación y autorización propias;
• reglas de negocio con propietario claro;
• versionado;
• migraciones controladas;
• capacidad de probar cada comportamiento sin depender del sistema anterior.

En la arquitectura actual:

• Solúcar actúa como frontend Angular;
• Alixar asume el backend y la autoridad de negocio;
• PostgreSQL proporciona la persistencia de la nueva plataforma.

Alrededor de esa base se están construyendo capacidades que quiero considerar estructurales:

• autenticación;
• autorización basada en roles y permisos;
• API versionada;
• persistencia evolucionable mediante migraciones;
• separación entre dominio, transporte y almacenamiento;
• contratos que permitan evolucionar consumidores y backend sin acoplarlos innecesariamente.

Seguridad y contratos no son detalles posteriores

En una plataforma que pretende sustituir progresivamente a otra, seguridad, contratos y versionado no deberían aparecer al final.

Si diferentes consumidores van a coexistir durante la transición, necesitamos contratos.

Si diferentes usuarios pueden realizar distintas operaciones, necesitamos autorización.

Si el sistema va a evolucionar mientras sigue utilizándose, necesitamos versionado.

Si los datos van a cambiar de estructura, necesitamos migraciones reproducibles.

No son características accesorias.

Son parte de la capacidad de modernizar sin perder el control.

Solúcar tampoco debe convertirse en propietario del negocio

La misma separación se aplica al frontend.

Angular puede:

• mostrar información;
• recoger datos;
• facilitar acciones;
• ofrecer una buena experiencia de usuario.

Pero no debería convertirse en el lugar donde viven las reglas críticas.

Si una transición no es válida, debe protegerla el backend.

Si un permiso impide una operación, debe garantizarlo el backend.

Si una restricción debe cumplirse independientemente del consumidor, debe pertenecer al dominio.

La interfaz puede ayudar.

No debe ser la autoridad.

Qué quiero demostrar con Alixar-Solúcar

El objetivo del proyecto no es demostrar únicamente que puedo construir una aplicación con Java, Spring Boot y Angular.

Eso sería demasiado poco.

Lo que quiero explorar es un problema más real:

cómo sustituir progresivamente un sistema empresarial sin perder el conocimiento que contiene y sin trasladar sus problemas estructurales a la nueva solución.

Eso obliga a:

1. comprender el comportamiento del legacy;
2. identificar las reglas de negocio;
3. decidir cuáles siguen siendo válidas;
4. diseñar un modelo nuevo;
5. establecer una arquitectura destino independiente;
6. trasladar capacidades progresivamente;
7. mover la autoridad sobre los datos de forma explícita;
8. migrar y reconciliar información;
9. validar los nuevos contratos;
10. retirar la dependencia del sistema anterior.

No es simplemente una reescritura.

Es una extracción controlada del conocimiento empresarial y de la autoridad sobre sus datos desde una implementación que ya no queremos conservar hacia otra que sí queremos poder evolucionar.

Puedes tirar el código. No tires el negocio.

Una aplicación puede quedarse obsoleta.

Su framework puede dejar de ser adecuado.

Su arquitectura puede impedir evolucionar.

Sus dependencias pueden convertirse en un problema.

Incluso puede llegar un momento en el que mantener su código tenga menos sentido que sustituirlo.

Pero después de años de uso puede seguir conteniendo algo extremadamente valioso:

el conocimiento de cómo funciona realmente la empresa.

Ese conocimiento no pertenece a PHP.

Ni a Java.

Ni a Angular.

Ni a Dolibarr.

Pertenece al negocio.

Y ésa es precisamente la parte que una buena modernización no debería perder.

Puedes tirar el código. No tires el negocio.