Definición corta

Propiedad de un sistema cuyos contratos entre API, reglas de negocio y pruebas que describen el comportamiento esperado son lo bastante localizables y lo bastante separados como para que un equipo sepa rehacerlo en otro sitio, en otra tecnología.

Definición detallada

La palabra circula en varios sentidos fuera de aquí. En explotación, designa la capacidad de regenerar un entorno idéntico a partir de sus fuentes y su configuración. En archivo y en ciencia de datos, designa la posibilidad de recuperar un dato o un resultado a partir de lo que se ha conservado.

En los artículos de este blog, el término designa una propiedad de comprensión, no de herramientas: un sistema es reconstruible cuando se sabría rehacerlo, lo que supone saber dónde están las fronteras — por dónde pasa el contrato de una interfaz, dónde viven las reglas de negocio, qué pruebas dicen el comportamiento esperado en lugar de la implementación actual. La reconstrucción no tiene que llevarse a cabo: sirve de pregunta de control, planteada en lugar de "¿esto funciona?".

El sentido normativo y el uso sobre el terreno divergen en un punto. La norma querría la reconstrucción idéntica, incluido el detalle de la implementación. Sobre el terreno, la pregunta planteada es más débil y más útil: ¿sabríamos obtener el mismo comportamiento con otros medios, partiendo de lo que el sistema dice de sí mismo?

Uso en el ámbito

El término interviene como criterio de calidad de un desarrollo asistido por un asistente, allí donde la velocidad de entrega ya no dice nada del dominio que se tiene. Sirve también en las decisiones de arquitectura — imponer contratos entre API, escribir la pirámide de pruebas antes de desarrollar, rechazar que el negocio quede disperso en los endpoints — y en las revisiones de fin de trabajo, como pregunta que sustituye a la demostración funcional.

Sinónimos y variantes

"¿Sabría reconstruirlo?" — la forma interrogativa es el uso corriente del término. Variantes acreditadas: "tener agarres sobre el sistema", "puntos de anclaje", "líneas de separación".

No confundir con

• Deuda de comprensión — pasivo acumulado por un equipo sobre un sistema que no explica; la reconstruibilidad es el activo correspondiente, y un equipo puede no tener ni lo uno ni lo otro sobre un sistema que aún no ha tocado.
• Reproducibilidad de una build — propiedad de una cadena de fabricación que produce el mismo artefacto a partir de las mismas entradas; se refiere a las herramientas y se verifica automáticamente, sin que ningún humano haya entendido lo que hace el sistema.
• Portabilidad — aptitud de un software para funcionar en otro entorno sin ser rehecho; evita la reconstrucción en lugar de hacerla posible.
• Documentación de arquitectura — descripción del estado del sistema tal como es; puede estar completa y dejar un sistema que no se sabría rehacer, así como puede faltar en un sistema cuyas pruebas bastan para decir el comportamiento.
• Deuda técnica — debilidad de diseño cuyo tratamiento se ha decidido y presupuestado; un sistema puede estar fuertemente endeudado y ser perfectamente reconstruible, ya que una cosa califica el diseño y la otra lo que se sabe decir de él.

Ejemplos

"Si mañana tengo que llevar esta aplicación a otra tecnología, sé dónde están los contratos, dónde están las reglas de negocio, dónde están las pruebas que describen el comportamiento esperado." — el empleo de referencia, aplicado a una aplicación desarrollada con un asistente.

Rechazar un enfoque DDD completo en un proyecto que no lo justifica, y rechazar a la vez que el negocio quede disperso en los endpoints, es un arbitraje de reconstruibilidad: no se busca la pureza del modelo, se buscan líneas de separación localizables.

Ambigüedades / debates

La amplitud buscada no está estabilizada: reconstruir el comportamiento, reconstruir la arquitectura o reconstruir el código. El sentido elegido aquí es el primero.

La verificación lo está aún menos. Nadie reconstruye para comprobar que habría sabido hacerlo, lo que deja el criterio en el estado de pregunta planteada en conciencia — y, por tanto, expuesto a la complacencia de quien responde.