Featured image of post Optimizando el "Query use case" usando SQL y "Read model"

Optimizando el "Query use case" usando SQL y "Read model"

Nos damos cuenta que el caso de uso que acabamos de ver tiene problemas de rendimiento. Hay que optimizarlo.

Nuestro Use case tarda demasiado en dar la información. Eso es debido a que usar la carta Ability - Persistence nos va bien en circunstancias normales, ya que asegura un guardado seguro y consistente, pero para leer es algo más lento. Este caso de uso se usa de forma intensiva y nos damos cuenta que en realidad no necesitamos toda la información que nos ofrece el Aggregate root. A su vez, debemos mejorar nuestra velocidad de respuesta.

Abriendo debate técnico

Agregando rendimiento de lectura al Use case. La vía rápida.

Vemos que no necesitamos bastantes datos del Aggregate root, es muy grande para nuestras necesidades.

Eso nos abre la puerta a enfocar el problema desde otra perspectiva, orientada específicamente a las necesidades del Use case que nos concierne.

En este caso, recurrimos ahora si, al concepto del Read model. Básicamente es una proyección de la información organizada de forma diferente a lo que sería nuestro Aggregate root.

Es en definitiva la misma información desde otro punto de vista, más o menos resumida y orientada al consumidor de dicha información.

Query use case, scenario 2, projection

Al ser algo orientado a ofrecer información, podemos hacer que el objeto sea muy liviano, sin lógica de dominio. Nos desharemos de todos los elementos de la capa Domain y usaremos nuestra carta de Read model en su lugar.

Query use case, scenario 2, read model

Como habéis podido comprobar. Al no usar elemento de la Domain layer, nuestro ORM ya no lo necesitamos, puesto que sólo conoce elementos de Dominio. En su lugar usaremos la carta de Persistence strategy - SQL para conseguir cartas de tipo Read model.

Cabe decir que un Read model aprovechando la misma información almacenada por el Command (que en este contexto sería el Write model) puede parecer un gran avance, pero más adelante veremos que el concepto de proyección alcanza unos niveles más elevados a medida que nuestro Use case se vuelve más exigente en los tiempos de respuesta.

Un Read model en estos escenarios nos aporta velocidad, a cambio de mayor coste de mantenimiento, ya que si cambia la estructura de nuestra información a través del Aggregate root, presumiblemente también lo hará nuestro Read model.

Nuestro escenario quedaría de la siguiente manera.

Query use case, scenario 2, read model

Licensed under CC BY-NC-SA 4.0
Creado con Hugo
Tema Stack diseñado por Jimmy