In Event Sourcing:
- A Projection is the State of the System at some point in time.
- An Event is the change that occurred to the "State of the System" at some point in time.
Regardless of how you cut it the state enters the system as an event, and is aggregated into a projection in order to facilitate processing.
So the questions are:
- Do I need
age in order to accomplish the work? Yes, then it needs to be persisted/added to the appropriate projection and the events that source it
- Do I need
age in order to accomplish a non-functional goal (such as recording it to settle legal requests)? Yes, then it needs to be persisted/added to the appropriate projection and the events that source it
Otherwise why do you have an event carrying
age? It should be eliminated as it is unnecessary overhead.
I am confused by why you seem to also be passing a user object along for the ride. This runs counter to the idea that all of the data is in the event stream, and will break your architecture.
I would refactor that dependency out. Ensure that the projections can handle this data, and issue a one time batch of events giving the appropriate properties to every current user. Perhaps issue events to mark non-current users as dead. This will push your code back toward the architecture, making it less confusing.
Alternately, stop considering this as an event sourcing system. The Projection becomes a request object, events are the problem of whomever assembles the request. Now it follows Command Query architecture and the reasonable answer is that user properties are on user. Failure to provide them will fail the request.