CQRS - allowed dependencies for building read model using events and other sources of information

Question

My question is related to CQRS (Command and Query Responsibility Segregation) and mechanism that builds read model (views). As far as I understand read model is built by event handlers. These handlers (also called denormalizers) receive domain events and use these events to build different views of data.

Specific event carries information about change done in domain model. I think that this information is not sufficient in some cases to build view - i.e. not changed fields, not changed entities are missing in such event etc.

So my question is:

Is it allowed that denormalizer responsible for building read model accesses not only events but also:

1. changed entity referenced directly in event?
2. changed aggregated root and any entity related to this aggregate?
3. any entity fetched from repository?
4. any view?

What is your opinion about allowed dependencies for event handlers (denormalizers)?

edit: Just added simple example to the question above:

Suppose the following model:

AR: ProductOffering * name * description * category * price

AR: Customer * name * type * method: purchaseProduct(productOffering) that emits ProductPurchasedByCustomer event

entity: ProductInstance * customer * productOffering

event: ProductPurchasedByCustomer * customerId * productOfferingId

view: ProductInventoryView * customerId * productOfferingId * customerType * productOfferingName * productOfferingCategory * price

How to build ProductInventoryView using only ProductPurchasedByCustomer event? How can I write denormalizer to put into view information about customerType, productOfferingName etc? Should I lookup additional information about customerType and productOfferingName from different views?

Answer 1

If an event consumer requires more information, it's okay for an event producer to provide that required information, eventhough it hasn't changed. Eventsourcing should not be treated like an ORM. Mind you things can become tricky with regard to how you get that information, but lets not complicate things (yet). The eventhandlers can use the state (data) of the read model if it's not provided by the event. But doing so requires you to know if and which data you can use. It requires you to couple time to the data. Messages/events are likely to be processed out of order. So, providing information in the event, pertaining to the event, is much easier. Try do that before doing anything else. Don't try to access your domain from the eventhandlers specific to your read model, that's just nasty coupling. One last thing, it's okay for aggregates to copy data from other aggregates to provide the data you need in your events. Mind you that from then on you'll have to start thinking on how to keep that data fresh in the aggregates that copied it in the first place. Probably confused you some more ...