Publicación
Cómo estamos construyendo Racoonity
Antes de crear productos, inventarios y ventas, necesitamos una base donde cada pieza sepa qué debe hacer y qué no.
Racoonity quiere comenzar siendo un sistema pequeño.
Eso no significa que deba construirse de cualquier manera.
Una aplicación puede parecer sencilla por fuera y, al mismo tiempo, estar formada por una sola pieza enorme en la que todo depende de todo. Al principio funciona. Después llegan nuevos módulos, reglas, permisos, automatizaciones e integraciones, y cada cambio comienza a sentirse como mover una pared sin saber qué parte del techo sostiene.
Nosotros queremos evitar ese camino desde el principio.
No construyendo una arquitectura gigantesca para problemas que todavía no existen, sino estableciendo unas cuantas fronteras claras antes de comenzar a llenar el sistema de funcionalidades.
Una ciudad, no una sola máquina
La forma más sencilla de explicar la arquitectura de Racoonity es imaginar una pequeña ciudad.
Dentro de ella existen distintas responsabilidades:
- Alguien conoce las capacidades disponibles.
- Alguien recibe las operaciones y las dirige al lugar correcto.
- Alguien responde consultas sin modificar información.
- Alguien verifica permisos.
- Alguien coordina los cambios que deben completarse juntos.
- Alguien registra los eventos que ocurrieron.
En lugar de colocar todas esas responsabilidades dentro de una sola pieza, Racoonity las divide en herramientas pequeñas y especializadas.
Algunas tienen nombres técnicos. También les hemos dado oficios de mapache para recordar fácilmente qué papel cumplen dentro del sistema.
Por ejemplo:
- Racoon Guildmaster conoce las capacidades que ofrece cada módulo.
- Racoon Dispatcher dirige una acción hacia el responsable correcto.
- Racoon Librarian recupera información sin cambiar el estado del sistema.
- Racoon Foreman coordina operaciones que deben confirmarse o revertirse completas.
Los nombres son simpáticos, pero la intención detrás de ellos es seria: cada herramienta debe tener una responsabilidad clara y límites que también sean claros.
Los dominios conservan sus propias reglas
Racoonity no quiere convertirse en una colección de pantallas conectadas directamente a tablas.
Productos, inventario, ventas, pagos, clientes y sesiones de caja representan problemas distintos. Cada uno debe proteger sus propias reglas.
El catálogo sabe qué es un producto.
El inventario sabe cuánto existe y dónde se encuentra.
Ventas sabe qué ocurrió comercialmente.
Pagos sabe cómo fue cubierta una venta.
Una pantalla puede combinar todas esas capacidades para completar una operación, pero no debe apropiarse de ellas.
Por ejemplo, el punto de venta podrá capturar productos, mostrar un total y solicitar un pago. Sin embargo, no será quien modifique directamente el inventario ni quien decida por sí mismo que una venta quedó confirmada.
La experiencia presenta la operación.
Los dominios conservan la verdad.
Contratos en lugar de atajos
Cuando una parte de Racoonity necesita solicitar algo a otra, queremos que lo haga mediante contratos públicos y reconocibles.
Una modificación se expresa como una acción.
Una lectura se expresa como una consulta.
Un hecho importante se expresa como un evento.
Esto evita que una pieza entre directamente a los datos privados de otra y realice cambios que nadie más puede controlar.
También nos permite saber con mayor claridad:
- quién puede ejecutar una operación;
- qué información necesita;
- qué resultado debe producir;
- qué errores pueden ocurrir;
- y qué partes deben confirmarse o revertirse juntas.
El objetivo no es añadir ceremonia por gusto.
El objetivo es que, cuando llegue el momento de incorporar nuevas capacidades, no tengamos que desmontar todo lo construido anteriormente.
Primero los cimientos, después la tienda
El primer resultado visible de Racoonity no será todavía una venta ni una pantalla de productos.
Antes necesitamos demostrar que el sistema puede:
- iniciar correctamente;
- conectarse a su base de datos;
- registrar sus capacidades;
- ejecutar una acción;
- responder una consulta;
- confirmar una operación completa;
- y revertirla si algo falla.
A esta primera etapa la llamamos el primer latido.
Puede parecer un comienzo poco emocionante comparado con mostrar un punto de venta funcionando. Pero es la prueba de que Racoonity ya posee una base sobre la cual podremos construir productos, inventario, clientes, caja y ventas sin improvisar sus fundamentos cada vez.
No queremos pasar años construyendo infraestructura invisible.
Tampoco queremos crear rápidamente muchas pantallas sobre cimientos que después tengamos que reemplazar.
La intención es avanzar mediante pequeñas rebanadas completas: cada etapa debe agregar una capacidad real y, al mismo tiempo, respetar las fronteras que permitirán seguir creciendo.
Simple no significa frágil
“Simple por defecto” describe la experiencia que queremos ofrecer.
No significa que internamente todo deba mezclarse para terminar más rápido.
La sencillez que buscamos debe sobrevivir al crecimiento.
Una tienda pequeña no debería verse obligada a comprender motores, contratos ni eventos para comenzar a trabajar. Todo eso debe permanecer detrás de escena, sosteniendo una experiencia clara.
Pero si con el tiempo esa operación necesita procesos más avanzados, campos personalizados, automatizaciones o nuevos módulos, Racoonity debe tener espacio para incorporarlos sin convertir la experiencia básica en un laberinto.
Ese es el equilibrio que estamos intentando construir:
Un sistema sencillo de usar, pero no sencillo de romper.
En la siguiente entrada hablaremos del primer resultado concreto de este enfoque: el momento en que Racoonity dejó de existir solamente en documentos y consiguió ejecutar, confirmar y revertir su primera operación real.