Aprovisionamiento de eventos y Generación de Modelos leídos

Personalmente creo que no hay nada malo en buscar el nombre del usuario desde el controlador de eventos. Pero si estás en una posición en la que no puedes consultar el nombre del modelo de lectura del Usuario, entonces presentaría un controlador de eventos adicional a QuestionEventsHandler, para manejar el evento registrado por el usuario.

De esa manera el QuestionEventsHandler podría mantener su propio repositorio de nombres de usuario (no necesitaría almacenar el correo electrónico de los usuarios). El controlador QuestionArked puede entonces consultar el nombre directo de su propio repositorio (como Rinat Abdullin dijo que el almacenamiento es barato!).

Además de que tu modelo QuestionItem read contiene el nombre del usuario, también necesitarás manejar el evento UserNameChanged dentro del controlador QuestionEventsHandler para asegurarte de que el campo name dentro del QuestionItem esté actualizado.

Para mí esto parece menos esfuerzo que 'enriquecer los eventos' y tiene el beneficio de no construir dependencias en otras partes del sistema y sus modelos leídos.

Extrae eventos del EventStore.

Recuerde: Sus modelos de lectura ya deben tener acceso de solo lectura al EventStore. Los modelos leídos son desechables. Son simplemente vistas en caché. Debería poder eliminar / caducar sus Modelos de lectura en cualquier momento y reconstruir automáticamente sus ReadModels desde EventStore. Por lo tanto, sus ReadModelBuilders ya deben poder consultar eventos pasados.

public class QuestionEventsHandler
{
    public void Handle(QuestionAsked question)
    {
        // Get Name of User
        var nameChangedEvent = eventRepository.GetLastEventByAggregateId<UserNameChanged>(question.UserId);

        var item = new QuestionItem(
            question.UserId, 
            question.QuestionId, 
            question.Title, 
            question.Question, 

            nameChangedEvent.Name
    }
}

También tenga en cuenta que el repositorio EventStore no necesita ser el verdadero EventStore, aunque ciertamente podría serlo. La ventaja de los sistemas distribuidos es que puede replicar fácilmente el EventStore, si lo necesita, más cerca de sus ReadModels.

Me encontré exactamente con el mismo escenario... donde necesitaba más datos de los que estaban disponibles en un solo evento. Esto es especialmente cierto para los eventos de tipo Create que requieren rellenar un nuevo ReadModel con el estado inicial.

De los Modelos Leídos: Se puede extraer de otros Modelos Leídos. Pero realmente no recomiendo esto, ya que introduciría una gran bola de lodo de dependencia donde las vistas dependen de las vistas dependen de las vistas.

Datos adicionales en Eventos: Realmente no quieres inflar tus eventos con todos los datos adicionales que necesitarás para las vistas. Realmente le hará daño cuando su dominio cambie y necesite migrar eventos. Los eventos de dominio tienen propósitos específicos: representan cambios de estado. No ver datos.

Espero que esto ayude -

Ryan