De CRUD (Crear, Leer, Actualizar, Eliminar) a CQRS (Segregación de responsabilidades de consultas y comandos): el problema es el modelo, no el código (DE Crud Crear Leer Actualizar Eliminar A CQRS Segregacion DE Responsabilidades DE Consultas Y Comandos El Problema Es El Modelo No El Codigo)

¿Por qué CRUD funciona muy bien durante años?

CRUD no está mal. Si su equipo está formado por tres personas, está desarrollando un solo producto y atiende unos cientos de solicitudes por día; La secuencia Controller → Service → Repository → Database es una solución perfecta. Es rápido, claro y fácil de entrar en la mente de un nuevo desarrollador.```text İlk gün

Product ↓ Controller ↓ Service ↓ Repository ↓ Database La rotura proviene del crecimiento del producto, no de la calidad del código. Al principio, solo enumeras productos. Al cabo de seis meses, el marketing pide un filtro; las ventas requieren clasificación; operación solicita exportación; La gerencia quiere un panel de control. El mismo patrón `Product` de repente termina sirviendo para veinte propósitos diferentes.text Marketing → filtre Sales → sorting Operations→ export Management→ analytics + dashboard

                ↓

          aynı Product modeli

Su signo en la vida cotidiana suele ser un punto final inocente:```text
Bugün
GET /products → 10 ms

Altı ay sonra
GET /products
  ↓ Category
  ↓ Reviews
  ↓ Seller
  ↓ Campaign
  ↓ Discount
  ↓ Stock
  ↓ Warehouse
  ↓ Shipment
  ↓ Favorites

aynı endpoint, farklı ekranları beslemek için büyür
```Breve glosario para jóvenes:```text
📦 Aggregate
İş kurallarını bir arada koruyan domain nesnesidir.

📦 Invariant
Her koşulda doğru kalması gereken iş kuralıdır.

📦 Transaction boundary
Ya hep ya hiç birlikte kaydedilmesi gereken işlemlerin sınırıdır.

📦 Projection
Bir olayı, okuma için hazırlanmış yeni bir görünüme dönüştüren işlemdir.

📦 Read model / DTO
Ekranın ihtiyacı kadar alan taşıyan, okumaya uygun veri görünümüdür.
```La historia de este artículo comienza desde este punto: CQRS reduce esta tensión no cambiando la tecnología, sino dando diferentes intenciones a diferentes modelos.

## ¿Cuándo crea CRUD un cuello de botella?

En el enfoque CRUD, la lectura y la escritura se encuentran en la misma representación. La parte que escribe quiere mantener las reglas, la coherencia y las transiciones. El lado de la lectura requiere filtrado rápido, DTO pequeños, búsqueda, clasificación y campos fáciles de visualizar. Cuando un único modelo intenta cubrir estas necesidades al mismo tiempo, surgen dos tipos de costes.

El primero es el coste técnico. Para una pantalla de lista simple, se cargan relaciones agregadas, se crean uniones innecesarias y aumenta el costo del acceso a los datos. El segundo es el costo cognitivo. Agregar un campo corrige el informe de un equipo y afecta la regla de transacción de otro equipo.```text
100 kullanıcı
  → tek API + tek model
  → CRUD yeterli

5.000 kullanıcı
  → liste, filtre, rapor, iş akışı
  → modelin niyetleri çatışmaya başlar

100.000 kullanıcı
  → okuma ve yazma yükü asimetrik
  → tek model değişimin maliyetini artırır
```Este flujo no ocurre en las mismas cantidades en todos los proyectos. La señal no es el número de usuarios; Ahora no está claro qué responsabilidad tiene el modelo.

## CQS: La raíz pequeña pero crítica de CQRS

El principio de separación de consultas de comandos de Bertrand Meyer es simple: **Hacer una pregunta no debería cambiar la respuesta.**

- El comando cambia de estado; Lleva intención y no tiene que devolver un valor.
- La consulta devuelve información; No cambia el estado observable.

Esta disciplina a nivel de método hace que el diseño de API sea más predecible. `ApproveInvoice` es un comando; `GetInvoiceSummary` es una consulta. `UpdateInvoiceStatus`, aunque técnicamente posible, oculta la intención del trabajo.

CQRS lleva esta idea al nivel arquitectónico. El modelo Command conserva las reglas e invariantes comerciales. El modelo de consulta produce la vista que el usuario o el sistema quiere ver. Podrán compartir la misma mesa; No son obligatorias dos bases de datos, Kafka o Event Sourcing.

## Donde choca un solo modelo

Consideremos un sistema de reservas. La parte emisora ​​debe mantener las reglas de capacidad, cancelación, pago y franja horaria. Por lo tanto, se requieren fronteras y transacciones sólidas. La pantalla de administración, por otro lado, quiere ver rápidamente la tasa de ocupación actual, resúmenes por ubicación y próximas reservas.

Alimentar estas dos intenciones con el mismo gráfico de entidad generalmente se convierte en este flujo ingenuo:```text
GET /reservations
  → Reservation aggregate + Customer + Payment + Availability
  → domain kurallarıyla iç içe sorgu
  → yavaş ve kırılgan liste ekranı
```La respuesta de CQRS es establecer dos objetivos de optimización separados:```text
Command: ReserveRoom
  → kapasiteyi doğrula
  → kuralları uygula
  → transaction içinde kaydet

Query: GetDailyOccupancy
  → sadece tarih, lokasyon ve sayıları oku
  → ekrana uygun DTO döndür
```A través de esta distinción, el modelo de escritura puede evolucionar hacia la precisión y el modelo de lectura puede evolucionar hacia la exploración y la velocidad. Esto no significa que cada consulta será O(1). Sin embargo, a menudo aproxima el costo al número de filas y campos en la vista de destino en lugar del gráfico de dominio completo.

## Señales de decisión para CQRS

CQRS no se elige porque esté de moda. Las siguientes señales adquieren significado cuando aparecen juntas en el mismo contexto delimitado:

1. **Interfaz basada en tareas:** Los usuarios hacen más que simplemente formar `Create`, `Update`; confirma, hace una reserva, inicia la entrega o solicita un reembolso. Los nombres de los comandos deben llevar el idioma comercial.
2. **Carga asimétrica:** El tráfico de lectura es significativamente mayor que el tráfico de escritura y los requisitos de consulta son diferentes de la forma del modelo de dominio.
3. **Regla comercial:** El agregado mantiene múltiples invariantes; La simple actualización de datos ya no indica la decisión empresarial.
4. **Ritmo de cambio independiente:** Las necesidades de interfaz de usuario y de informes cambian más rápido que las reglas del lado de la creación.
5. **Contexto delimitado abierto:** El idioma, la propiedad y los criterios de éxito del área que implementará la distinción son claros.

Ésta no es una lista de verificación, sino evidencia para la decisión. La señal más fuerte suele ser esta: si el equipo está negociando constantemente para cambiar tanto el comportamiento como la apariencia de la misma entidad, el modelo está haciendo dos trabajos diferentes.

## ¿Qué no es CQRS?

Hay cinco discrepancias que encarecen innecesariamente el CQRS.

- CQRS no se trata de reescribir todo el sistema. Sólo puede comenzar en un contexto acotado complejo.
- CQRS no son dos bases de datos físicas. En primer lugar, se puede hacer una distinción lógica en el código.
- CQRS no es abastecimiento de eventos. Se pueden utilizar juntos pero no son requisitos previos el uno para el otro.
- CQRS no es un requisito del intermediario de mensajes. Los manejadores en proceso pueden ser suficientes para empezar.- CQRS no se trata de convertir cada pantalla en un microservicio.

Especialmente en paneles de administración simples, reglas comerciales superficiales y baja tasa de cambio, el CRUD clásico es una mejor opción. Menos piezas significa menos operaciones y una incorporación más sencilla. La madurez arquitectónica no se trata de qué tan rápido se agrega CQRS; Se mide por cómo sabes cuándo no sumar.

## Compensación: ¿qué ganas, qué pagas?

| Ganancias | Precio |
| --- | --- |
| Comandos con intención comercial | Más modelos y contratos |
| Consultas rápidas adecuadas para escenarios de uso | Gestión de datos duplicados |
| Evolución independiente de la lectura y la escritura | Flujos adicionales a observar |
| Opción de escalado en carga asimétrica | Máxima coherencia en la distinción física |

Por lo tanto, la decisión de CQRS no es una elección de marco, sino una función de costos: la complejidad estructural que agregue debe ser menor que la complejidad operativa y de dominio que elimine.

## Manera segura de comenzar

El camino más seguro comienza con la separación lógica, no con la separación física. Separe los nombres de comandos y consultas por idioma comercial. Descargue consultas en DTO apropiados para la visualización. Aclarar la validación, la autoridad y los límites invariantes en el lado del Comando. Toma medidas. Sin embargo, cuando exista un cuello de botella de lectura comprobado o se necesite una escala independiente, mueva el modelo de lectura a un repositorio separado.

Este enfoque establece un sistema de aprendizaje en lugar de un salto arquitectónico irreversible.

Exploraremos esta distinción en la siguiente sección: ¿Cómo funcionan juntos los canales de comandos y consultas, los comportamientos del mediador, el límite de transacciones y la selección de la bandeja de salida?

## Conceptos que se confunden con más frecuencia```text
❌ CQRS = Event Sourcing
❌ CQRS = Microservice
❌ CQRS = Kafka
❌ CQRS = Event-driven architecture

✓ Bunlar birbirinden bağımsız yaklaşımlardır.
✓ Birlikte kullanılabilirler; birbirlerinin şartı değildir.
```Considere primero el CQRS como una separación de responsabilidades. Solo se debe agregar una base de datos, un corredor o un flujo de eventos por separado si satisface una necesidad medida.

## Matriz de decisión

| Tamaño | CRUD | CQRS |
| --- | --- | --- |
| Simplicidad de inicio del código | Alto | Medio |
| Facilidad de mantenimiento, dominio sencillo | Alto | Medio |
| Escala de lectura asimétrica | Limitado | Fuerte |
| Regla de dominio denso | Se vuelve más difícil con el tiempo | Fronteras más visibles |
| Costo de operación | Bajo | Medio en discriminación lógica, alto en discriminación física |

Esto no es un cuadro de mando; Es una herramienta de decisión que hace visible el contexto. Para un dominio simple, la alta simplicidad de CRUD es una ventaja real.

> **CRUD no es un problema para sistemas pequeños. El problema es que un único modelo intenta representar diferentes intenciones simultáneamente. CQRS resuelve este problema no cambiando la tecnología, sino separando responsabilidades.**