Pasamos los primeros seis meses de VenduSys creando modelos para todo. Al llegar al cuarto mes, teníamos diecisiete entidades, ocho tablas de unión, tres objetos de «contexto» que nadie sabía definir con exactitud y un modelo de permisos que tardábamos veinte minutos en explicar. Todo un clásico.
Entonces lo descartamos y partimos de una pregunta: ¿cuál es el conjunto más pequeño de entidades que puede modelar todas las formas de comercio que nos interesan?
La respuesta resultó ser cuatro.
Fiesta
Una persona, organización o agente. Compradores, vendedores, operadores, socios… todos ellos son representaciones del mismo registro. La diferencia entre «comprador» y «vendedor» no es una categoría, sino un papel que se desempeña en una transacción. Un comprador en una operación es un vendedor en la siguiente.
Una vez que aceptas eso, la identidad se convierte en un problema de grafos más que en un problema de tipado. KYB, KYC, roles, auditoría, configuración de pagos… todo cuelga del mismo nodo.
Cosa
Cualquier cosa que se ofrezca o se posea. Productos, licencias, servicios, suscripciones, activos, tiempo. Las variantes y los paquetes son proyecciones adicionales: una SKU es una «cosa» con una forma concreta, un plan de suscripción es una «cosa» con una dimensión temporal y una hora de servicio es una «cosa» con una dimensión de capacidad.
La mayoría de las plataformas de comercio las modelan como entidades independientes (producto, plan, servicio, activo) y luego se pasan años subsanando las deficiencias. Al tratarlas como una sola entidad con atributos —perpetuos o limitados en el tiempo, físicos o digitales, transferibles o no—, se reduce una cantidad sorprendente de complejidad.
Mover
Un evento que transfiere valor o derechos entre las partes. Pedidos, devoluciones, renovaciones, transferencias, reembolsos, reclamaciones… todo ello son movimientos. Un movimiento tiene un pagador, un beneficiario, un elemento (o conjunto de elementos), un importe y un estado.
Al modelar «pedido» y «reembolso» como el mismo tipo de objeto —con signos diferentes—, se elimina toda una categoría de errores.
Entrada
Una línea del libro mayor de doble partida. Cada movimiento genera asientos; los informes y los saldos se derivan de ellos de forma determinista. Se trata de la entidad más importante del sistema y la que la mayoría de las plataformas comerciales ocultan.
Si tu plataforma es un sistema de registro de transacciones monetarias, pero tu libro mayor es una cuestión secundaria, tu plataforma es un sistema de negación plausible.
Por qué funciona esto
La clave no son las cuatro entidades. La clave es lo que te impiden tener:
- No existen tipos de órdenes distintos como «orden de mercado» y «orden directa»
- No hay una distinción entre «suscripción» y «compra única»: ambas son secuencias de pasos
- No hay una «cartera» independiente: el saldo es la suma de los movimientos de una cuenta
- No existe un «motor de reembolsos» independiente: un reembolso es una operación de anulación con asientos contables de anulación.
- No existe un «libro mayor de socios» independiente: los pagos a los socios son simplemente asientos en las cuentas de los socios.
La forma en el código
A grandes rasgos, en TypeScript:
type Party = { id; kind: 'person' | 'org' | 'machine'; profile; trust };
type Thing = { id; kind; attrs; rights?; meter? };
type Move = { id; kind; from: PartyId; to: PartyId; thing: ThingId[];
at; state; reverses?: MoveId };
type Entry = { id; account; move: MoveId;
side: 'debit' | 'credit'; amount; ccy };Todo lo demás —pedidos, facturas, suscripciones, programas para socios, mercados— forma parte de un flujo de trabajo que los integra. La biblioteca de flujos de trabajo es tema de otra entrada.
Lo que dejamos atrás
Hay que reconocer que aporta cierta claridad. «Pedido» y «Suscripción» son términos útiles en las conversaciones con personas que no son ingenieros. Los mantenemos como proyecciones en la interfaz de la API, pero, en el fondo, no son más que secuencias de operaciones. Esa diferencia es el coste.
A cambio, hemos conseguido un sistema que no se colapsa cuando aparece una nueva forma. Sabremos que hemos acertado con el modelo si nunca tenemos que añadir una quinta entidad. Vuelve a preguntarnos dentro de tres años.
Edwin Korver is the founder and systems architect behind VenduSys and RoundMap®. His work focuses on regenerative business, value orchestration, and the systems that help organizations move from extraction toward shared value and healthier ecosystems.