Event Sourcing and Read Model generation

Question

Assuming Stack Overflow domain problem and the following definition of events:

UserRegistered(UserId, Name, Email)
UserNameChanged(UserId, Name)
QuestionAsked(Us         


        

Answer 1

Just enrich the event with all the necessary information.

Greg's approach, as I recall, - enrich the event while creating and store/publish it this way.

Answer 2

Pull events from the EventStore.

Remember - Your read models need to have read-only access to the EventStore already. Read Models are disposable. They are simply cached views. You should be able to delete / expire your Read Models at any time - and automatically rebuild your ReadModels from the EventStore. So - your ReadModelBuilders must already be able to query for past events.

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
    }
}

Also realize - the EventStore repository need not be the true EventStore, although it certainly could be. The advantage of distributed systems is that you can easily replicate the EventStore, if you needed, closer to your ReadModels.

I encountered this exact same scenario... where I needed more data than was available in a single event. This is especially true for Create-type events which require populating a new ReadModel with initial state.

From Read Models: You could pull from other Read Models. But I really don't recommend this, as you would introduce a big ball of dependency mud where views depend on views depend on views.

Additional Data in Events: You really don't want to bloat your events with all the extra data you'll need for views. It will really hurt you when your domain changes & you need to migrate events. Domain Events have specific purposes - they represent state changes. Not view data.

Hope this helps -

Ryan

Answer 3

Personally I think there's nothing wrong with looking up the user's name from within the event handler. But if you're in a position where you can't query the name from the User's read model then I'd introduce an additional event handler to QuestionEventsHandler, to handle the UserRegistered event.

That way the QuestionEventsHandler could maintain its own repository of user names (you wouldn't need to store the users email). The QuestionAsked handler can then query the user's name direct from it's own repository (as Rinat Abdullin said storage is cheap!).

Besides since your QuestionItem read model holds the user's name, you would need to handle the UserNameChanged event within the QuestionEventsHandler as well to ensure the name field within the QuestionItem is up-to-date.

To me this seems less effort than 'enriching the events' and has the benefit of not building dependencies on other parts of the system and their read models.