El problema que nadie nombra

Hay un momento en la vida de casi todo sistema de software en que el código deja de escalar, no por falta de servidores ni por una base de datos lenta, sino por algo más silencioso: la confusión entre lo que el sistema hace y lo que el sistema sabe. Escribir y leer mezclados en las mismas clases, los mismos métodos, los mismos flujos. Cuando algo falla, es difícil saber si el error está en la lógica de transformación del estado o en la lógica de consulta. Y cuando algo funciona, tampoco queda del todo claro por qué.

auroraCQRS nació en abril de 2022 como un ejercicio de claridad. Una implementación del patrón CQRS sobre NestJS en TypeScript, un ejemplo concreto de separar comandos de consultas. Nada más, nada menos. Pero esa separación tiene una profundidad que va más allá del patrón en sí.

CQRS como filosofía de la intención

Command Query Responsibility Segregation —CQRS— es un nombre largo para una idea simple: los mensajes que cambian el estado del mundo son fundamentalmente distintos de los mensajes que preguntan sobre él. Un comando dice "crea esto", "elimina aquello", "actualiza esto otro". Una consulta dice "dime cómo están las cosas ahora mismo". Mezclarlos en el mismo objeto o en el mismo método no es solo un problema de diseño; es un problema epistémico. Se está confundiendo la acción con el conocimiento.

En filosofía hay una distinción antigua entre el saber proposicional —saber que algo es así— y el saber práctico —saber cómo hacer algo. CQRS, aunque nadie lo formule así, opera sobre una línea similar: separar el conocimiento del mundo (la lectura) de la capacidad de transformarlo (la escritura). Cuando esa separación existe en el código, el sistema empieza a hablar con más precisión sobre sus propias intenciones.

Lo que NestJS y TypeScript aportan

auroraCQRS usa el módulo CQRS de NestJS, un framework que en 2022 ya había madurado lo suficiente para ofrecer abstracciones decentes sobre comandos y eventos. TypeScript hace el resto: los tipos obligan a ser explícito sobre qué tipo de mensaje se está enviando, qué handler lo recibe, qué forma tiene el resultado. No hay ambigüedad que el compilador tolere en silencio.

Esa combinación —NestJS + TypeScript + CQRS— no es arbitraria. Es la elección de alguien que quiere que el código comunique su arquitectura antes de que el lector llegue a la lógica de negocio. El directorio de comandos no mezcla queries. El directorio de queries no tiene efectos secundarios. Cada cosa en su lugar, y el lugar hace evidente la intención.

Por qué esto importa más que el CRUD

El CRUD —crear, leer, actualizar, eliminar— es el lenguaje de los tutoriales. Es útil, es suficiente para muchos problemas pequeños, y es exactamente lo que la mayoría aprende primero. Pero el CRUD es mudo respecto a la intención del dominio. Un endpoint de actualización no dice nada sobre por qué se actualiza, qué reglas gobiernan esa actualización, qué consecuencias tiene en el resto del sistema.

CQRS no reemplaza el CRUD; lo transciende. Un comando no es un PUT disfrazado. Es una declaración de intención en el lenguaje del dominio: "registrar un nuevo usuario", "aprobar una solicitud", "cancelar un pedido". Cada comando encapsula una acción con significado propio, y el handler que lo procesa contiene toda la lógica que esa acción requiere. La pregunta que responde una consulta tampoco es un GET genérico: es una vista específica del estado del sistema, optimizada para quien la consume.

Esa granularidad de intención es lo que hace que los sistemas grandes puedan crecer sin convertirse en maraña.

El primer salto

auroraCQRS fue creado en un solo día —el commit inicial y el último push tienen menos de tres horas de diferencia— pero esa velocidad no habla de descuido. Habla de que el patrón ya estaba claro antes de empezar a escribir. El proyecto es pequeño, deliberadamente. No tiene base de datos, no tiene autenticación, no tiene capas de complejidad accidental. Es un sketch arquitectónico: la forma sin el contenido, para demostrar que la forma importa.

Hay algo instructivo en hacer proyectos así. No todo el código que uno escribe necesita llegar a producción ni resolver un problema de negocio. A veces escribir código es pensar en voz alta sobre estructuras, sobre separaciones, sobre qué ocurre cuando se impone disciplina donde antes había libertad sin forma. auroraCQRS es eso: un pensamiento arquitectónico escrito en TypeScript.

Lo que enseña sobre sistemas

Separar comandos de consultas tiene una consecuencia que no siempre se anticipa: obliga a pensar en el dominio antes de pensar en la implementación. No se puede diseñar un buen set de comandos sin entender qué acciones tiene sentido en ese dominio. No se pueden diseñar buenas consultas sin entender qué preguntas se van a hacer y desde qué perspectiva.

Esa obligación es una forma de disciplina intelectual. El código que respeta CQRS tiende a ser código que primero modeló el problema, luego lo tradujo. Y esa secuencia —modelo, luego traducción— es exactamente la diferencia entre ingeniería de software y programación de scripts.

auroraCQRS fue el primer salto en esa dirección: la primera señal documentada de pensar en sistemas más allá del CRUD, de tomar en serio la arquitectura como una decisión filosófica sobre cómo un programa entiende y transforma el mundo.