La demo que nos obligó a definir Racoon Artifier

Hay una pregunta que probablemente no aparece en demasiados libros de arquitectura de software:

Who the fook is that guy?

En nuestro caso, that guy era Racoon Artifier.

La intención original era bastante sencilla: comenzar a diseñar una demostración conceptual para Racoonity Lab, una superficie pública donde pudiéramos experimentar con algunas de las ideas centrales del proyecto sin esperar a que todo el producto estuviera terminado.

La demo podría mostrar una tabla dinámica de productos, alternar entre una lista y un formulario, agregar un campo personalizado, cambiar permisos o visualizar qué engines participaban en una operación.

No necesitaba conectarse todavía al backend real. Podía ser una simulación pequeña, aislada y claramente presentada como experimento.

Parecía una tarea bastante razonable.

Hasta que comenzamos a definir qué debía demostrar.

La demo se trataba de Artifier

Una parte importante del experimento consistía en mostrar que un administrador podía extender Racoonity sin modificar directamente el código fuente.

Por ejemplo:

Abrir Racoon Artifier
→ seleccionar Product
→ agregar el campo warranty_months
→ publicar la definición
→ ver el nuevo campo en el formulario

También queríamos representar algo más ambicioso:

Crear el modelo Reparaciones
→ definir sus campos
→ generar lista, formulario y detalle
→ crear su navegación
→ comenzar a operar registros

El problema apareció al intentar traducir estas ideas a una demo concreta.

¿Racoon Artifier era el editor de campos?

¿Era un constructor de modelos?

¿Era el diseñador de vistas?

¿También debía crear menús?

¿Ejecutaba las Actions que configuraba?

¿Persistía los registros dinámicos?

¿Renderizaba las interfaces?

¿Era responsable de los workflows?

¿Incluía Blueprints?

¿Era una aplicación, un engine, un runtime o una colección de herramientas?

La respuesta implícita parecía ser:

Sí.

Y cuando una pieza arquitectónica comienza a responder “sí” a todas las preguntas, normalmente no estamos frente a una herramienta particularmente poderosa.

Estamos frente a una futura clase Dios con un logotipo bonito.

Un nombre que había comenzado a absorberlo todo

Artifier no había aparecido completamente de la nada.

Durante las primeras conversaciones sobre Racoonity ya existía la idea de una superficie avanzada desde la que un usuario pudiera personalizar el sistema.

En distintos momentos la llamamos Studio, Racoonity Studio, Racoon Artificer y Racoonity Artifier.

El nombre cambiaba, pero la ambigüedad permanecía.

Dentro de esa misma idea habíamos colocado:

• Campos personalizados.
• Modelos personalizados.
• Vistas dinámicas.
• Menús.
• Experiencias guiadas.
• Actions configurables.
• Expresiones.
• Blueprints.
• Workflows.
• Módulos instalables.
• Un agente conversacional.

Prácticamente cualquier cosa avanzada que no tuviera todavía un lugar claro terminaba dentro de “Studio”.

Era una palabra cómoda porque nos permitía hablar de la visión sin resolver aún todas sus fronteras.

El problema fue que la demo ya no nos permitía seguir aplazando la pregunta.

Para representar Artifier necesitábamos saber qué hacía realmente.

La demo no falló

Nuestra primera reacción pudo haber sido recortar la demo.

Podíamos limitarla a una tabla editable, algunos controles simulados y una animación donde apareciera un campo nuevo.

Habría sido suficiente para mostrar algo visualmente interesante.

Pero también habría ocultado el problema.

La demo no estaba fallando por falta de diseño ni por falta de implementación.

Estaba revelando que todavía no habíamos terminado de comprender uno de los conceptos principales de Racoonity.

Y ésa terminó siendo su aportación más valiosa.

A veces una demo no sirve para demostrar que una idea funciona. A veces sirve para demostrar que todavía no has terminado de entender la idea.

En lugar de continuar simulando una herramienta indefinida, detuvimos el experimento y regresamos a la arquitectura.

Artifier construye; los engines ejecutan

La respuesta final parece sencilla después de escribirla:

Racoon Artifier construye y configura. Los engines especializados resuelven, validan, ejecutan, persisten o renderizan.

Artifier no es un único engine.

Es la superficie general de personalización y extensión de Racoonity.

Desde ella, un usuario podrá construir definiciones declarativas mediante diferentes herramientas especializadas:

Racoon Artifier
├── Model Builder
├── View Builder
├── Navigation Builder
├── Experience Builder
├── Action Builder
├── Expression Builder
├── Blueprint Builder
├── Workflow Builder
├── Module Builder
└── Artifier Agent

Estos builders describen lo que el usuario desea construir.

No sustituyen a los componentes encargados de hacerlo funcionar.

Por ejemplo, cuando un administrador agrega un campo personalizado:

Artifier captura la definición
→ Dispatcher recibe la Action
→ Bouncer autoriza
→ Inspector valida
→ Metadata conserva la definición publicada
→ Atlas invalida y vuelve a resolver
→ Painter muestra el campo
→ Warehouse persiste su valor

Artifier participa en el recorrido, pero no se apropia de todas sus responsabilidades.

No ejecuta la Action por fuera de Racoon Dispatcher.

No sustituye la autorización de Racoon Bouncer.

No reemplaza la validación de Racoon Inspector.

No resuelve metadata en lugar de Racoon Atlas.

No persiste los datos en lugar de Racoon Warehouse.

No renderiza la interfaz en lugar de Racoon Painter.

Y cuando existan workflows, tampoco los ejecutará: esa responsabilidad pertenecerá a Racoon Conductor.

La primera versión será mucho más pequeña

Definir la visión completa también nos permitió reducir con precisión su primera entrega.

En el primer MVP, Racoon Artifier no será todavía el entorno capaz de construir cualquier cosa imaginable.

Su alcance se limitará a tres herramientas:

• Model Builder v1, para campos y modelos personalizados.
• View Builder v1 limitado, para listas, formularios y detalles básicos.
• Navigation Builder v1 automático, para generar acceso a los modelos personalizados.

Quedarán fuera, entre otras cosas:

• El diseñador libre de layouts.
• Los flujos por pasos.
• Experience Builder completo.
• Actions personalizadas.
• Expresiones y campos calculados.
• Blueprints.
• Workflows.
• Racoon Conductor operativo.
• Module Builder.
• Artifier Agent.

Estas ideas no desaparecieron.

Simplemente dejaron de mezclarse con la primera versión.

Eso nos permite construir una base pequeña sin cerrar la puerta al monstruo futuro.

Una pequeña demo movió toda la documentación

La consecuencia ligeramente absurda fue que una demo que todavía no habíamos comenzado a implementar terminó obligándonos a revisar buena parte de la documentación canónica de Racoonity.

Tuvimos que alinear:

• La definición del primer MVP.
• El mapa de capacidades y dominios.
• La arquitectura mínima de engines.
• Los recorridos operativos.
• El plan de iteraciones.
• El contexto maestro de arquitectura.
• La visión futura de Artifier.
• El manifiesto de evolución del producto.

También reemplazamos los nombres anteriores y separamos conceptos que habían permanecido unidos por comodidad.

Blueprints dejaron de ser sinónimo de workflows.

Artifier dejó de ser el runtime de todo.

Metadata conservó ownership sobre las definiciones publicadas.

Racoon Scribe recibió la coordinación de registros dinámicos.

Racoon Conductor quedó reservado como runtime futuro de workflows.

Y la iteración destinada a Artifier pudo finalmente describir un resultado concreto y verificable.

La lección

En proyectos grandes es tentador pensar que primero debemos terminar de planear y después comenzar a prototipar.

Esta experiencia nos recordó que el prototipo también forma parte de la planeación.

Intentar representar una idea obliga a responder preguntas que pueden permanecer escondidas durante páginas enteras de documentación.

¿Quién posee esta definición?

¿Quién la valida?

¿Quién la ejecuta?

¿Quién persiste el resultado?

¿Qué parte pertenece al MVP?

¿Qué parte es únicamente visión futura?

¿Estamos diseñando una herramienta especializada o depositando dentro de ella todo lo que todavía no sabemos clasificar?

Racoonity Lab todavía tendrá su demo.

Pero ahora, cuando abramos Racoon Artifier dentro de ella, sabremos al menos quién demonios es ese sujeto.

Y, quizá más importante, quién no es.