Quiero implementar mi primera aplicación usando el patrón CQRS junto con Event Sourcing. Me pregunto cómo se debe manejar adecuadamente la creación de raíces agregadas. Digamos que alguien envía el comando CreateItem. ¿Cómo se debe manejar? ¿Dónde debe almacenarse el evento ItemCreated? ¿Como primer evento de un nuevo artículo? ¿O debería tener algún tipo de entidad ItemList que agregue todos los elementos y su lista de eventos consista solo en eventos ItemCreated?
Udi Dahan sugiere no crear raíces agregadas y usar siempre algún tipo de método de recuperación. Pero cómo puedo obtener algo que es nuevo y ciertamente no tiene ninguna identificación asignada. Entiendo la idea detrás y es bastante razonable pensar que un nuevo objeto es un objeto que tiene su estado compuesto de cero eventos respondidos. ¿Pero cómo debo usarlo? ¿Debería tener un método distinto en mi repositorio getNewItem()o hacer que mi get(id)método acepte en su Optional<ItemId>lugar?
Editar: Después de un tiempo de excavación, encontré una implementación realmente interesante de los patrones antes mencionados utilizando actores. El autor, en lugar de crear el agregado, lo recupera de algún tipo de repositorio con UUID recién creado. El inconveniente de este enfoque es que permite un estado de inconsistencia temporal. También me pregunto cómo puedo implementar el deletemétodo con ese enfoque. ¿Simplemente agregue Evento eliminado a la lista de eventos del agregado?
Respuestas:
La idea en la publicación de Udi, según tengo entendido, es que ningún tipo de artículo aparece de la nada. Hay (casi) siempre algo, o más específicamente, alguna operación de dominio, que causó la creación del elemento. Al igual que el ejemplo de Udi de un usuario que realmente nació de un visitante que se registra en el sitio. En ese punto y en ese contexto acotado, Visitor es la raíz agregada, que es recuperada por su dirección IP. Este visitante crea el nuevo "elemento", un usuario en este punto, a través de una operación de dominio llamada Registro . Lo mismo ocurre con el paso anterior, que es otro contexto acotado: el referente es el AR, que es recuperado por la URL y que tiene una operación de dominio llamada BroughtVisitorWithIp , donde nace el visitante.
Udi también escribe muy bien sobre la eliminación: http://www.udidahan.com/2009/09/01/dont-delete-just-dont/ . La idea principal es que nunca elimines nada. Siempre hay una operación de dominio detrás, que queremos capturar. Como un pedido que se cancela, en lugar de eliminarse. Léelo, es una muy buena publicación.
El punto principal aquí en ambas cuentas, haciendo DDD y especialmente Event Sourcing, es que nunca debes hacer operaciones CRUD directas. Si se encuentra en una situación en la que realmente necesita insertar, actualizar o eliminar algunos datos, y realmente no hay una operación de dominio detrás de ellos, entonces tal vez DDD y Event Sourcing no sean una buena opción para ese contexto limitado . Usted es libre de combinar estos dos como desee, siempre y cuando un contexto limitado se adhiera a un principio. De esta forma, el contexto acotado de estilo CRUD podría crear una fila en la base de datos, que se convierte en una entidad y una raíz Agregada en otro contexto acotado, donde ahora puede recuperar el AR y no tener que crearlo.
fuente