Me pregunto cómo se asegura de no agregar a la misma persona dos veces en su EventStore.

Supongamos que en su aplicación agrega datos de personas pero desea asegurarse de que el mismo nombre de persona y fecha de nacimiento no se agreguen dos veces en diferentes transmisiones.

¿Le pregunta a ReadModels o lo hace dentro de su Evenstore?

0
Burim Hajrizaj 6 dic. 2019 a las 15:37

2 respuestas

La mejor respuesta

Me pregunto cómo se asegura de no agregar a la misma persona dos veces en su EventStore.

La forma generalizada del problema que está intentando resolver es establecer validación.

El paso n. ° 1 es hacer retroceder el requisito de garantizar que los datos sean siempre únicos: si no tiene que ser siempre único, puede utilizar un enfoque de detección y corrección. Consulte Memorias, suposiciones y disculpas por Pat Helland. Traducida, hace lo mejor que puede con la información que tiene y realiza una copia de seguridad si resulta que tiene que revertir un error.

Si una violación de unicidad lo expondría a un riesgo inaceptable (por ejemplo, ser demandado a la quiebra porque la duplicación viola los requisitos de privacidad obligatorios del gobierno), entonces debe trabajar.

Para validar la unicidad del conjunto, debe bloquear todo el conjunto; Este bloqueo puede ser pesimista u optimista en la implementación. Eso es relativamente sencillo cuando todo el conjunto se almacena en un solo lugar (es decir, bajo un solo bloqueo), pero es una pesadilla cuando el conjunto se distribuye (también conocido como múltiples bases de datos).

Si su conjunto es un agregado (lo que significa que los miembros del conjunto están siendo tratados como un todo único para fines de actualización), entonces la mecánica de DDD es sencilla. Cargue el conjunto en la memoria desde el "repositorio", realice cambios en el conjunto, conserve los cambios.

Este diseño está bien con el abastecimiento de eventos en el que cada agregado tiene una sola secuencia: se protege contra las razas bloqueando "la" secuencia.

La mayoría de la gente no quiere este diseño, porque los miembros del conjunto son grandes, y para la mayoría de los datos solo necesita una pequeña porción de esos datos, por lo que cargar / almacenar todo el conjunto en la memoria de trabajo es un desperdicio.

Entonces, lo que hacen es mover la responsabilidad de mantener la propiedad de unicidad del modelo de dominio al almacenamiento. Las soluciones RDBMS son realmente buenas en conjuntos . Usted define la restricción que mantiene la propiedad, y la base de datos asegura que no se permiten escrituras que violen la restricción.

Si su tienda de eventos es una base de datos relacional, puede hacer lo mismo: la secuencia de eventos y la tabla que mantiene su conjunto invariante se actualizan juntos dentro de la misma transacción.

Si su tienda de eventos no es una base de datos relacional? Bueno, de nuevo, debe mirar el dinero: si el riesgo es lo suficientemente alto, entonces tiene que descartar las tuberías que no le permiten resolver el problema de las tuberías que sí lo hacen.

En algunos casos, hay otro enfoque: codificar la información que debe ser única en el identificador de flujo. La transmisión viene a representar "Todos los usuarios llamados Bob", y luego su modelo de dominio puede asegurarse de que la transmisión Bob contenga como máximo un usuario activo a la vez.

Luego comienza a pensar si el nombre Bob es estable y qué compensaciones está dispuesto a hacer cuando cambia un nombre inestable.

Los nombres de personas son un problema particularmente miserable, porque ninguno de las cosas que creemos acerca de los nombres son verdaderas. Entonces obtienes todos los problemas habituales con singularidad, marcados hasta once.

1
VoiceOfUnreason 6 dic. 2019 a las 14:32

Si vas a validar este tipo de cosas, entonces debes hacerlo en el agregado IMO, y tendrías que usar modelos de lectura para eso como dices. Pero terminas enviando códigos de infraestructura / dependencias a tus agregados / pasados a tus métodos.

En este caso, sugeriría crear un modelo de lectura de Person.Id, Person.Name, Person.Birthday y luego, en lugar de crear un Person directamente, cree algún servicio que use el modelo de lectura tabla para buscar si existe o no una fila y devolverle ese agregado o crear uno nuevo y devolverlo. Entonces no necesitará validar en absoluto, siempre que toda la creación de Persona se realice a través de este servicio.

1
thisextendsthat 6 dic. 2019 a las 14:51